[Intel-gfx] [drm-tip:drm-tip 7/8] debug.c:undefined reference to `save_stack_trace'

[kbuild test robot]

Hi Rodrigo,

It's probably a bug fix that unveils the link errors.

tree:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
head:   20532651221ed29af16e2db0a7ec8b9bd482c994
commit: 315fade0d9f3edbf2592599056c8defbdd95a3ab [7/8] Merge remote-tracking 
branch 'drm-intel/topic/core-for-CI' into drm-tip
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 315fade0d9f3edbf2592599056c8defbdd95a3ab
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=m68k 

All errors (new ones prefixed by >>):

   kernel/dma/debug.o: In function `dma_entry_alloc':
>> debug.c:(.text+0x11d2): undefined reference to `save_stack_trace'
   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+0x12b4): 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] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Andrew Morton]

On Mon, 16 Jul 2018 13:50:58 +0200 Michal Hocko  wrote:

> From: Michal Hocko 
> 
> There are several blockable mmu notifiers which might sleep in
> mmu_notifier_invalidate_range_start and that is a problem for the
> oom_reaper because it needs to guarantee a forward progress so it cannot
> depend on any sleepable locks.
> 
> ...
>
> @@ -571,7 +565,12 @@ static bool oom_reap_task_mm(struct task_struct *tsk, 
> struct mm_struct *mm)
>  
>   trace_start_task_reaping(tsk->pid);
>  
> - __oom_reap_task_mm(mm);
> + /* failed to reap part of the address space. Try again later */
> + if (!__oom_reap_task_mm(mm)) {
> + up_read(>mmap_sem);
> + ret = false;
> + goto unlock_oom;
> + }

This function is starting to look a bit screwy.

: static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
: {
:   if (!down_read_trylock(>mmap_sem)) {
:   trace_skip_task_reaping(tsk->pid);
:   return false;
:   }
: 
:   /*
:* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
:* work on the mm anymore. The check for MMF_OOM_SKIP must run
:* under mmap_sem for reading because it serializes against the
:* down_write();up_write() cycle in exit_mmap().
:*/
:   if (test_bit(MMF_OOM_SKIP, >flags)) {
:   up_read(>mmap_sem);
:   trace_skip_task_reaping(tsk->pid);
:   return true;
:   }
: 
:   trace_start_task_reaping(tsk->pid);
: 
:   /* failed to reap part of the address space. Try again later */
:   if (!__oom_reap_task_mm(mm)) {
:   up_read(>mmap_sem);
:   return true;
:   }
: 
:   pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, 
file-rss:%lukB, shmem-rss:%lukB\n",
:   task_pid_nr(tsk), tsk->comm,
:   K(get_mm_counter(mm, MM_ANONPAGES)),
:   K(get_mm_counter(mm, MM_FILEPAGES)),
:   K(get_mm_counter(mm, MM_SHMEMPAGES)));
:   up_read(>mmap_sem);
: 
:   trace_finish_task_reaping(tsk->pid);
:   return true;
: }

- Undocumented return value.

- comment "failed to reap part..." is misleading - sounds like it's
  referring to something which happened in the past, is in fact
  referring to something which might happen in the future.

- fails to call trace_finish_task_reaping() in one case

- code duplication.


I'm thinking it wants to be something like this?

: /*
:  * Return true if we successfully acquired (then released) mmap_sem
:  */
: static bool oom_reap_task_mm(struct task_struct *tsk, struct mm_struct *mm)
: {
:   if (!down_read_trylock(>mmap_sem)) {
:   trace_skip_task_reaping(tsk->pid);
:   return false;
:   }
: 
:   /*
:* MMF_OOM_SKIP is set by exit_mmap when the OOM reaper can't
:* work on the mm anymore. The check for MMF_OOM_SKIP must run
:* under mmap_sem for reading because it serializes against the
:* down_write();up_write() cycle in exit_mmap().
:*/
:   if (test_bit(MMF_OOM_SKIP, >flags)) {
:   trace_skip_task_reaping(tsk->pid);
:   goto out;
:   }
: 
:   trace_start_task_reaping(tsk->pid);
: 
:   if (!__oom_reap_task_mm(mm)) {
:   /* Failed to reap part of the address space. Try again later */
:   goto finish;
:   }
: 
:   pr_info("oom_reaper: reaped process %d (%s), now anon-rss:%lukB, 
file-rss:%lukB, shmem-rss:%lukB\n",
:   task_pid_nr(tsk), tsk->comm,
:   K(get_mm_counter(mm, MM_ANONPAGES)),
:   K(get_mm_counter(mm, MM_FILEPAGES)),
:   K(get_mm_counter(mm, MM_SHMEMPAGES)));
: finish:
:   trace_finish_task_reaping(tsk->pid);
: out:
:   up_read(>mmap_sem);
:   return true;
: }

- Increases mmap_sem hold time a little by moving
  trace_finish_task_reaping() inside the locked region.  So sue me ;)

- Sharing the finish: path means that the trace event won't
  distinguish between the two sources of finishing.

Please take a look?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v3] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Srivatsa, Anusha]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, July 20, 2018 3:59 PM
>To: Srivatsa, Anusha 
>Cc: intel-gfx@lists.freedesktop.org; Navare, Manasi D
>
>Subject: Re: [v3] drm/i915/dsc: Add missing _MMIO() from PPS registers
>
>On Fri, Jul 20, 2018 at 02:42:42PM -0700, Anusha Srivatsa wrote:
>> This patch fixes the commit -
>> <2efbb2f099fb> ("i915/dp/dsc: Add DSC PPS register definitions"),
>> which did not have _MMIO() for DSCA and DSCC.
>>
>> v2: Fix typos. (manasi)
>>
>> v3: Change the commit message (Rodrigo)
>>
>> Cc: Rodrigi Vivi 
>> Cc: Manasi Navare 
>> Signed-off-by: Anusha Srivatsa 
>> Reviewed-by: Manasi Navare 
>
>pushed to dinq, thanks
Thanks you very much!

Anusha 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h | 76
>> -
>>  1 file changed, 38 insertions(+), 38 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 8af945d..7394605 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN   (1 << 23)
>>
>>  /* Icelake Display Stream Compression Registers */
>> -#define DSCA_PICTURE_PARAMETER_SET_00x6B200
>> -#define DSCC_PICTURE_PARAMETER_SET_00x6BA00
>> +#define DSCA_PICTURE_PARAMETER_SET_0_MMIO(0x6B200)
>> +#define DSCC_PICTURE_PARAMETER_SET_0_MMIO(0x6BA00)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB0x78270
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB0x78370
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC0x78470
>> @@ -10370,8 +10370,8 @@ enum skl_power_gate {
>>  #define  DSC_VER_MIN_SHIFT  4
>>  #define  DSC_VER_MAJ(0x1 << 0)
>>
>> -#define DSCA_PICTURE_PARAMETER_SET_10x6B204
>> -#define DSCC_PICTURE_PARAMETER_SET_10x6BA04
>> +#define DSCA_PICTURE_PARAMETER_SET_1_MMIO(0x6B204)
>> +#define DSCC_PICTURE_PARAMETER_SET_1_MMIO(0x6BA04)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB0x78274
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB0x78374
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC0x78474
>> @@ -10384,8 +10384,8 @@ enum skl_power_gate {
>>
>_ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
>>  #define  DSC_BPP(bpp)   ((bpp) << 0)
>>
>> -#define DSCA_PICTURE_PARAMETER_SET_20x6B208
>> -#define DSCC_PICTURE_PARAMETER_SET_20x6BA08
>> +#define DSCA_PICTURE_PARAMETER_SET_2_MMIO(0x6B208)
>> +#define DSCC_PICTURE_PARAMETER_SET_2_MMIO(0x6BA08)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB0x78278
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB0x78378
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC0x78478
>> @@ -10399,8 +10399,8 @@ enum skl_power_gate {
>>  #define  DSC_PIC_WIDTH(pic_width)   ((pic_width) << 16)
>>  #define  DSC_PIC_HEIGHT(pic_height) ((pic_height) << 0)
>>
>> -#define DSCA_PICTURE_PARAMETER_SET_30x6B20C
>> -#define DSCC_PICTURE_PARAMETER_SET_30x6BA0C
>> +#define DSCA_PICTURE_PARAMETER_SET_3_MMIO(0x6B20C)
>> +#define DSCC_PICTURE_PARAMETER_SET_3_MMIO(0x6BA0C)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB0x7827C
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB0x7837C
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC0x7847C
>> @@ -10414,8 +10414,8 @@ enum skl_power_gate {
>>  #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
>>  #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
>>
>> -#define DSCA_PICTURE_PARAMETER_SET_40x6B210
>> -#define DSCC_PICTURE_PARAMETER_SET_40x6BA10
>> +#define DSCA_PICTURE_PARAMETER_SET_4_MMIO(0x6B210)
>> +#define DSCC_PICTURE_PARAMETER_SET_4_MMIO(0x6BA10)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB0x78280
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB0x78380
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC0x78480
>> @@ -10429,8 +10429,8 @@ enum skl_power_gate {
>>  #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
>>  #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
>>
>> -#define DSCA_PICTURE_PARAMETER_SET_50x6B214
>> -#define DSCC_PICTURE_PARAMETER_SET_50x6BA14
>> +#define DSCA_PICTURE_PARAMETER_SET_5_MMIO(0x6B214)
>> +#define DSCC_PICTURE_PARAMETER_SET_5_MMIO(0x6BA14)
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB0x78284
>>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB0x78384
>>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC0x78484
>> @@ -10441,11 +10441,11 @@ enum skl_power_gate {
>>  #define ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe)  _MMIO_PIPE((pipe) -
>PIPE_B, \
>>

Re: [Intel-gfx] [PATCH] mm, oom: distinguish blockable mode for mmu notifiers

[Andrew Morton]

On Tue, 17 Jul 2018 10:12:01 +0200 Michal Hocko  wrote:

> > Any suggestions regarding how the driver developers can test this code
> > path?  I don't think we presently have a way to fake an oom-killing
> > event?  Perhaps we should add such a thing, given the problems we're
> > having with that feature.
> 
> The simplest way is to wrap an userspace code which uses these notifiers
> into a memcg and set the hard limit to hit the oom. This can be done
> e.g. after the test faults in all the mmu notifier managed memory and
> set the hard limit to something really small. Then we are looking for a
> proper process tear down.

Chances are, some of the intended audience don't know how to do this
and will either have to hunt down a lot of documentation or will just
not test it.  But we want them to test it, so a little worked step-by-step
example would help things along please.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v3] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 02:42:42PM -0700, Anusha Srivatsa wrote:
> This patch fixes the commit -
> <2efbb2f099fb> ("i915/dp/dsc: Add DSC PPS register definitions"),
> which did not have _MMIO() for DSCA and DSCC.
> 
> v2: Fix typos. (manasi)
> 
> v3: Change the commit message (Rodrigo)
> 
> Cc: Rodrigi Vivi 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> Reviewed-by: Manasi Navare 

pushed to dinq, thanks

> ---
>  drivers/gpu/drm/i915/i915_reg.h | 76 
> -
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8af945d..7394605 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>  
>  /* Icelake Display Stream Compression Registers */
> -#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200
> -#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
> +#define DSCA_PICTURE_PARAMETER_SET_0 _MMIO(0x6B200)
> +#define DSCC_PICTURE_PARAMETER_SET_0 _MMIO(0x6BA00)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 0x78470
> @@ -10370,8 +10370,8 @@ enum skl_power_gate {
>  #define  DSC_VER_MIN_SHIFT   4
>  #define  DSC_VER_MAJ (0x1 << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_1 0x6B204
> -#define DSCC_PICTURE_PARAMETER_SET_1 0x6BA04
> +#define DSCA_PICTURE_PARAMETER_SET_1 _MMIO(0x6B204)
> +#define DSCC_PICTURE_PARAMETER_SET_1 _MMIO(0x6BA04)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB 0x78274
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB 0x78374
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC 0x78474
> @@ -10384,8 +10384,8 @@ enum skl_power_gate {
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
>  #define  DSC_BPP(bpp)((bpp) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_2 0x6B208
> -#define DSCC_PICTURE_PARAMETER_SET_2 0x6BA08
> +#define DSCA_PICTURE_PARAMETER_SET_2 _MMIO(0x6B208)
> +#define DSCC_PICTURE_PARAMETER_SET_2 _MMIO(0x6BA08)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB 0x78278
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB 0x78378
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC 0x78478
> @@ -10399,8 +10399,8 @@ enum skl_power_gate {
>  #define  DSC_PIC_WIDTH(pic_width)((pic_width) << 16)
>  #define  DSC_PIC_HEIGHT(pic_height)  ((pic_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_3 0x6B20C
> -#define DSCC_PICTURE_PARAMETER_SET_3 0x6BA0C
> +#define DSCA_PICTURE_PARAMETER_SET_3 _MMIO(0x6B20C)
> +#define DSCC_PICTURE_PARAMETER_SET_3 _MMIO(0x6BA0C)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB 0x7827C
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB 0x7837C
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC 0x7847C
> @@ -10414,8 +10414,8 @@ enum skl_power_gate {
>  #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
>  #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_4 0x6B210
> -#define DSCC_PICTURE_PARAMETER_SET_4 0x6BA10
> +#define DSCA_PICTURE_PARAMETER_SET_4 _MMIO(0x6B210)
> +#define DSCC_PICTURE_PARAMETER_SET_4 _MMIO(0x6BA10)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB 0x78280
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB 0x78380
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC 0x78480
> @@ -10429,8 +10429,8 @@ enum skl_power_gate {
>  #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
>  #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_5 0x6B214
> -#define DSCC_PICTURE_PARAMETER_SET_5 0x6BA14
> +#define DSCA_PICTURE_PARAMETER_SET_5 _MMIO(0x6B214)
> +#define DSCC_PICTURE_PARAMETER_SET_5 _MMIO(0x6BA14)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB 0x78284
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB 0x78384
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC 0x78484
> @@ -10441,11 +10441,11 @@ enum skl_power_gate {
>  #define ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_5_PC, \
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_5_PC)
> -#define  DSC_SCALE_DEC_INTINT(scale_dec) ((scale_dec) << 16)
> +#define  DSC_SCALE_DEC_INT(scale_dec)((scale_dec) << 16)
>  #define  DSC_SCALE_INC_INT(scale_inc)((scale_inc) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_6 0x6B218
> -#define DSCC_PICTURE_PARAMETER_SET_6 0x6BA18
> +#define DSCA_PICTURE_PARAMETER_SET_6 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: Add missing _MMIO() from PPS registers (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Add missing _MMIO() from PPS registers (rev3)
URL   : https://patchwork.freedesktop.org/series/46979/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9741 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)

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

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   NOTRUN -> INCOMPLETE (fdo#103713)


 Possible fixes 

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

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947
  fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4521 -> Patchwork_9741

  CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4570: 65cdccdc7bcbb791d791acb784a382110a3c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9741: 2d67170971143977f59b4852f29c888fcb3b0d18 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2d6717097114 drm/i915/dsc: Add missing _MMIO() from PPS registers

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9741/issues.html
___
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 [CI,1/2] drm/i915/dp: Limit link training clock recovery loop

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915/dp: Limit link training clock 
recovery loop
URL   : https://patchwork.freedesktop.org/series/46992/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9740 =

== Summary - SUCCESS ==

  No regressions found.

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  {fi-cfl-8109u}: PASS -> INCOMPLETE


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).



== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4521 -> Patchwork_9740

  CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4570: 65cdccdc7bcbb791d791acb784a382110a3c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9740: 5ef35ff56fb327ef9636123ad27755fffdd06f59 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

5ef35ff56fb3 drm/i915/dp: Refactor max_vswing_tries variable
cd42a90b0a51 drm/i915/dp: Limit link training clock recovery loop

== Logs ==

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

[Intel-gfx] [v3] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Anusha Srivatsa]

This patch fixes the commit -
<2efbb2f099fb> ("i915/dp/dsc: Add DSC PPS register definitions"),
which did not have _MMIO() for DSCA and DSCC.

v2: Fix typos. (manasi)

v3: Change the commit message (Rodrigo)

Cc: Rodrigi Vivi 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Manasi Navare 
---
 drivers/gpu/drm/i915/i915_reg.h | 76 -
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8af945d..7394605 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10349,8 +10349,8 @@ enum skl_power_gate {
 #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
 
 /* Icelake Display Stream Compression Registers */
-#define DSCA_PICTURE_PARAMETER_SET_0   0x6B200
-#define DSCC_PICTURE_PARAMETER_SET_0   0x6BA00
+#define DSCA_PICTURE_PARAMETER_SET_0   _MMIO(0x6B200)
+#define DSCC_PICTURE_PARAMETER_SET_0   _MMIO(0x6BA00)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB   0x78270
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB   0x78370
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC   0x78470
@@ -10370,8 +10370,8 @@ enum skl_power_gate {
 #define  DSC_VER_MIN_SHIFT 4
 #define  DSC_VER_MAJ   (0x1 << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_1   0x6B204
-#define DSCC_PICTURE_PARAMETER_SET_1   0x6BA04
+#define DSCA_PICTURE_PARAMETER_SET_1   _MMIO(0x6B204)
+#define DSCC_PICTURE_PARAMETER_SET_1   _MMIO(0x6BA04)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB   0x78274
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB   0x78374
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC   0x78474
@@ -10384,8 +10384,8 @@ enum skl_power_gate {
   
_ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
 #define  DSC_BPP(bpp)  ((bpp) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_2   0x6B208
-#define DSCC_PICTURE_PARAMETER_SET_2   0x6BA08
+#define DSCA_PICTURE_PARAMETER_SET_2   _MMIO(0x6B208)
+#define DSCC_PICTURE_PARAMETER_SET_2   _MMIO(0x6BA08)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB   0x78278
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB   0x78378
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC   0x78478
@@ -10399,8 +10399,8 @@ enum skl_power_gate {
 #define  DSC_PIC_WIDTH(pic_width)  ((pic_width) << 16)
 #define  DSC_PIC_HEIGHT(pic_height)((pic_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_3   0x6B20C
-#define DSCC_PICTURE_PARAMETER_SET_3   0x6BA0C
+#define DSCA_PICTURE_PARAMETER_SET_3   _MMIO(0x6B20C)
+#define DSCC_PICTURE_PARAMETER_SET_3   _MMIO(0x6BA0C)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB   0x7827C
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB   0x7837C
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC   0x7847C
@@ -10414,8 +10414,8 @@ enum skl_power_gate {
 #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
 #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_4   0x6B210
-#define DSCC_PICTURE_PARAMETER_SET_4   0x6BA10
+#define DSCA_PICTURE_PARAMETER_SET_4   _MMIO(0x6B210)
+#define DSCC_PICTURE_PARAMETER_SET_4   _MMIO(0x6BA10)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB   0x78280
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB   0x78380
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC   0x78480
@@ -10429,8 +10429,8 @@ enum skl_power_gate {
 #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
 #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_5   0x6B214
-#define DSCC_PICTURE_PARAMETER_SET_5   0x6BA14
+#define DSCA_PICTURE_PARAMETER_SET_5   _MMIO(0x6B214)
+#define DSCC_PICTURE_PARAMETER_SET_5   _MMIO(0x6BA14)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB   0x78284
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB   0x78384
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC   0x78484
@@ -10441,11 +10441,11 @@ enum skl_power_gate {
 #define ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_5_PC, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_5_PC)
-#define  DSC_SCALE_DEC_INTINT(scale_dec)   ((scale_dec) << 16)
+#define  DSC_SCALE_DEC_INT(scale_dec)  ((scale_dec) << 16)
 #define  DSC_SCALE_INC_INT(scale_inc)  ((scale_inc) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_6   0x6B218
-#define DSCC_PICTURE_PARAMETER_SET_6   0x6BA18
+#define DSCA_PICTURE_PARAMETER_SET_6   _MMIO(0x6B218)
+#define DSCC_PICTURE_PARAMETER_SET_6   _MMIO(0x6BA18)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PB   0x78288
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_6_PB   0x78388
 #define 

[Intel-gfx] [CI 1/2] drm/i915/dp: Limit link training clock recovery loop

[Rodrigo Vivi]

From: Nathan Ciobanu 

Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely requesting something
like:

voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage swing: 0, pre-emphasis level: 3

over and over so max_vswing would never be reached,
drm_dp_clock_recovery_ok() would never return true and voltage_tries
would always get reset to 1. The driver sends those values to the hub
but the hub keeps requesting new values every time.

Changes in v2:
- updated commit message (DK, Manasi)
- defined DP_DP14_MAX_CR_TRIES (Marc)
- made the loop iterate for max 10 times (Rodrigo, Marc)

Changes in v3:
- changed error message to use DP_DP14_MAX_CR_TRIES

Changes in v4:
- Updated the title to reflect the change
- Updated the commit message
- Added 80 attempts for pre-DP 1.4 devices

Changes in v5:
- Removed DP_DP14_MAX_CR_TRIES from drm

v6: Updated comment to match kernel style (Rodrigo)

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Cc: Manasi Navare 
Signed-off-by: Nathan Ciobanu 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 4da6e33c7fa1..299cad5632ed 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,7 @@ static bool
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries;
+   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -170,9 +170,20 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
return false;
}
 
+   /*
+* DP 1.4 spec clock recovery retries defined but
+* for devices pre-DP 1.4 we set the retry limit
+* to 4 (voltage levels) x 4 (preemphasis levels) x
+* x 5 (same voltage retries) = 80 (max iterations)
+*/
+   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+   max_cr_tries = 10;
+   else
+   max_cr_tries = 80;
+
voltage_tries = 1;
max_vswing_tries = 0;
-   for (;;) {
+   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
@@ -216,6 +227,8 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
++max_vswing_tries;
 
}
+   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
+   return false;
 }
 
 /*
-- 
2.17.1

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

[Intel-gfx] [CI 2/2] drm/i915/dp: Refactor max_vswing_tries variable

[Rodrigo Vivi]

From: Nathan Ciobanu 

Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.

Changes in v2:
- updated the title and commit message
- left the loop exit point in place

v3: fix typo in title
v4: renamed max_vswing to max_vswing_reached (Ville)

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Signed-off-by: Nathan Ciobanu 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 299cad5632ed..07e128c7443c 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,8 @@ static bool
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
+   int voltage_tries, cr_tries, max_cr_tries;
+   bool max_vswing_reached = false;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -182,7 +183,6 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
max_cr_tries = 80;
 
voltage_tries = 1;
-   max_vswing_tries = 0;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
@@ -203,7 +203,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
return false;
}
 
-   if (max_vswing_tries == 1) {
+   if (max_vswing_reached) {
DRM_DEBUG_KMS("Max Voltage Swing reached\n");
return false;
}
@@ -224,7 +224,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp 
*intel_dp)
voltage_tries = 1;
 
if (intel_dp_link_max_vswing_reached(intel_dp))
-   ++max_vswing_tries;
+   max_vswing_reached = true;
 
}
DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
-- 
2.17.1

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

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 11:01:38PM +0200, Marcin Owsiany wrote:
>2018-07-20 22:22 GMT+02:00 Rodrigo Vivi <[1]rodrigo.v...@intel.com>:
> 
>On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
>> $ xrandr --fb 8960x2880
>> xrandr: screen cannot be larger than 8192x8192 (desired size
>>8960x2880)
> 
>  I'm afraid that it is a hardware limitation that you won't be able
>  to
>  workaround.
> 
>Interestingly, just yesterday Ville Syrjälä posted a patch series for
>"GTT remapping for display",
>which concludes in this hopeful-looking patch called "Bump gen4+ fb
>size limits to 32kx32k:
>[2]https://lists.freedesktop.org/archives/intel-gfx/2018-July/171922.ht
>ml
>Which looks oddly similar to what I encountered on reddit.
>I don't pretend to even understand what "GTT remapping" is, but maybe
>there is hope after all? ;-)

cool...  I have that series on my todo list here to take a look but I
haven't yet. I'm glad to hear that there's hope.

> 
>  But a log would be interesting anyway... (both dmesg and xorg.0.log)
> 
>I'll try digging up that patched kernel sometime and get the messages.
> 
>  >My current workaround is to pretend that the displays are
>  arranged
>  >vertically, but even after a few months I'm sometimes having
>  trouble
>  >remembering that I need to move mouse cursor UP when I want to
>  go to
>  >LEFT display :-)
>  This is another bug And probably the right (only?) fixable fr
>  your
>  setup.
> 
>Why is this a bug? What I meant is that two wide monitors fit
>within 8192x8192
>when using xrandr's --above but not --left-of, so I'm just using the
>former despite
>having a different physical arrangement.
>Marcin
>PS: Sorry for the initial double-post, I thought my first email was
>blackholed

np... I approved it as soon as I saw it there.
list is open, but I have to filter the non-subscribed emails because of
so many spams...

>while I was not yet subscribed to the list.
> 
> References
> 
>1. mailto:rodrigo.v...@intel.com
>2. https://lists.freedesktop.org/archives/intel-gfx/2018-July/171922.html

> ___
> 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: Show debugfs dpcd read failure directly

[Dhinakaran Pandiyan]

On Fri, 2018-07-20 at 10:41 -0700, Rodrigo Vivi wrote:
> Instead of using a backchannel if some dpcd read failed we
> can show that directly on debugfs output.
> 
> We are not returning an error because we might still want
> to know if sub-sequent reads works,

We can print partial ( and successful) output and return the first
error value we get.

We should probably get rid of that warn_on too.

>  but we shouldn't
> need to check 2 places to see why reg is not on the list.
> 
> Cc: Jani Nikula 
> Cc: Dhinakaran Pandiyan 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 59dc0610ea44..5d8da4e8c444 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -4846,8 +4846,8 @@ static int i915_dpcd_show(struct seq_file *m,
> void *data)
>  
>   err = drm_dp_dpcd_read(_dp->aux, b->offset,
> buf, size);
>   if (err <= 0) {
> - DRM_ERROR("dpcd read (%zu bytes at %u)
> failed (%zd)\n",
> -   size, b->offset, err);
> + seq_printf(m, "dpcd read (%zu bytes at %u)
> failed (%zd)\n",
> +    size, b->offset, err);
>   continue;
>   }
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix psr sink status report.

[Dhinakaran Pandiyan]

On Fri, 2018-07-20 at 10:38 -0700, Rodrigo Vivi wrote:
> On Thu, Jul 19, 2018 at 06:52:00PM -0700, Dhinakaran Pandiyan wrote:
> > 
> > On Thu, 2018-07-19 at 17:31 -0700, Rodrigo Vivi wrote:
> > > 
> > > First of all don't try to read dpcd if PSR is not even supported.
> > > 
> > > But also, if read failed return -EIO instead of reporting via a
> > > backchannel.
> > > 
> > > v2: fix dev_priv: At this level m->private is the connector.
> > > (CI/DK)
> > > don't convert dpcd read errors to EIO. (DK)
> > > 
> > > Fixes: 5b7b30864d1d ("drm/i915/psr: Split sink status into a
> > > separate
> > > debugfs node")
> > > Cc: Chris Wilson 
> > > Cc: Dhinakaran Pandiyan 
> > > Cc: José Roberto de Souza 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
> > >  1 file changed, 11 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index b3aefd623557..59dc0610ea44 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2606,13 +2606,22 @@ static int
> > > i915_psr_sink_status_show(struct
> > > seq_file *m, void *data)
> > >   "sink internal error",
> > >   };
> > >   struct drm_connector *connector = m->private;
> > > + struct drm_i915_private *dev_priv = to_i915(connector-
> > > >dev);
> > >   struct intel_dp *intel_dp =
> > >   enc_to_intel_dp(_attached_encoder(connecto
> > > r)-
> > > > 
> > > > base);
> > > + int ret;
> > > +
> > > + if (!CAN_PSR(dev_priv)) {
> > > + seq_puts(m, "PSR Unsupported\n");
> > > + return -ENODEV;
> > > + }
> > >  
> > >   if (connector->status != connector_status_connected)
> > >   return -ENODEV;
> > >  
> > > - if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS,
> > > )
> > > == 1) {
> > > + ret = drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS,
> > > );
> > > +
> > > + if (ret == 1) {
> > >   const char *str = "unknown";
> > >  
> > >   val &= DP_PSR_SINK_STATE_MASK;
> > > @@ -2620,7 +2629,7 @@ static int i915_psr_sink_status_show(struct
> > > seq_file *m, void *data)
> > >   str = sink_status[val];
> > >   seq_printf(m, "Sink PSR status: 0x%x [%s]\n",
> > > val,
> > > str);
> > >   } else {
> > dpcd_readb() is not expected to return anything other than 1 or a
> > negative error code, so this looks good.
> > Reviewed-by: Dhinakaran Pandiyan 
> thanks, pushed.
> 
> > 
> > 
> > 
> > Are you also sending a similar fix for i915_dpcd_show()? That
> > function
> > also prints a DRM_ERROR() for failed aux transactions.
> well... it is a bit different there because we cannot return in the
> middle
> of the loop because we might want to get other regs read. but
> probably it
> is a good idea to print the error message along with the reads so you
> don't
> have to look to 2 places.
> 
> I will put a simple patch and we can wait until Jani is back from
> vacation since he was the author there.

Okay.

> 
> > 
> > 
> > > 
> > > - DRM_ERROR("dpcd read (at %u) failed\n",
> > > DP_PSR_STATUS);
> > > + return ret;
> > >   }
> > >  
> > >   return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Marcin Owsiany]

2018-07-20 22:22 GMT+02:00 Rodrigo Vivi :

> On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
> > $ xrandr --fb 8960x2880
> > xrandr: screen cannot be larger than 8192x8192 (desired size
> >8960x2880)
>
> I'm afraid that it is a hardware limitation that you won't be able to
> workaround.


Interestingly, just yesterday Ville Syrjälä posted a patch series for "GTT
remapping for display",
which concludes in this hopeful-looking patch called "Bump gen4+ fb size
limits to 32kx32k:
https://lists.freedesktop.org/archives/intel-gfx/2018-July/171922.html

Which looks oddly similar to what I encountered on reddit.

I don't pretend to even understand what "GTT remapping" is, but maybe there
is hope after all? ;-)


> But a log would be interesting anyway... (both dmesg and xorg.0.log)
>

I'll try digging up that patched kernel sometime and get the messages.


>
> >My current workaround is to pretend that the displays are arranged
> >vertically, but even after a few months I'm sometimes having trouble
> >remembering that I need to move mouse cursor UP when I want to go to
> >LEFT display :-)
>
> This is another bug And probably the right (only?) fixable fr your
> setup.
>

Why is this a bug? What I meant is that two wide monitors fit
within 8192x8192
when using xrandr's --above but not --left-of, so I'm just using the former
despite
having a different physical arrangement.

Marcin

PS: Sorry for the initial double-post, I thought my first email was
blackholed
while I was not yet subscribed to the list.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6] drm/i915/dp: Limit link training clock recovery loop

[Nathan Ciobanu]

On Fri, Jul 20, 2018 at 01:28:44PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 20, 2018 at 01:15:59PM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 attempts at
> > LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> > pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> > x 5 identical voltages tries). Some faulty USB-C MST hubs can
> > cause us to get stuck in this loop indefinitely requesting something
> > like:
> > 
> > voltage swing: 0, pre-emphasis level: 2
> > voltage swing: 1, pre-emphasis level: 2
> > voltage swing: 0, pre-emphasis level: 3
> > 
> > over and over so max_vswing would never be reached,
> > drm_dp_clock_recovery_ok() would never return true and voltage_tries
> > would always get reset to 1. The driver sends those values to the hub
> > but the hub keeps requesting new values every time.
> > 
> > Changes in v2:
> > - updated commit message (DK, Manasi)
> > - defined DP_DP14_MAX_CR_TRIES (Marc)
> > - made the loop iterate for max 10 times (Rodrigo, Marc)
> > 
> > Changes in v3:
> > - changed error message to use DP_DP14_MAX_CR_TRIES
> > 
> > Changes in v4:
> > - Updated the title to reflect the change
> > - Updated the commit message
> > - Added 80 attempts for pre-DP 1.4 devices
> > 
> > Changes in v5:
> > - Removed DP_DP14_MAX_CR_TRIES from drm
> > 
> > v6: Updated comment to match kernel style (Rodrigo)
> 
> thanks... you could've added my rv-b directly as well ;)
Why should it be simple when I can make it complicated, right? :D. 
Hopefully less noob mistakes next time.
> 
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Cc: Marc Herbert 
> > Cc: Manasi Navare 
> > Signed-off-by: Nathan Ciobanu 
> 
> anyway
> 
> Reviewed-by: Rodrigo Vivi 
> 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +++--
> >  1 file changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 4da6e33c7fa1..299cad5632ed 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> >  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  {
> > uint8_t voltage;
> > -   int voltage_tries, max_vswing_tries;
> > +   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
> > uint8_t link_config[2];
> > uint8_t link_bw, rate_select;
> >  
> > @@ -170,9 +170,20 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > return false;
> > }
> >  
> > +   /*
> > +* DP 1.4 spec clock recovery retries defined but
> > +* for devices pre-DP 1.4 we set the retry limit
> > +* to 4 (voltage levels) x 4 (preemphasis levels) x
> > +* x 5 (same voltage retries) = 80 (max iterations)
> > +*/
> > +   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> > +   max_cr_tries = 10;
> > +   else
> > +   max_cr_tries = 80;
> > +
> > voltage_tries = 1;
> > max_vswing_tries = 0;
> > -   for (;;) {
> > +   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
> > uint8_t link_status[DP_LINK_STATUS_SIZE];
> >  
> > drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> > @@ -216,6 +227,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > ++max_vswing_tries;
> >  
> > }
> > +   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> > +   return false;
> >  }
> >  
> >  /*
> > -- 
> > 1.9.1
> > 
> > ___
> > 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] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Srivatsa, Anusha]

>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, July 20, 2018 1:37 PM
>To: Srivatsa, Anusha 
>Cc: Navare, Manasi D ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS
>registers
>
>On Fri, Jul 20, 2018 at 08:28:01PM +, Srivatsa, Anusha wrote:
>>
>>
>> >-Original Message-
>> >From: Navare, Manasi D
>> >Sent: Friday, July 20, 2018 1:29 PM
>> >To: Vivi, Rodrigo 
>> >Cc: Srivatsa, Anusha ; intel-
>> >g...@lists.freedesktop.org
>> >Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from
>> >PPS registers
>> >
>> >On Fri, Jul 20, 2018 at 01:13:07PM -0700, Rodrigo Vivi wrote:
>> >> On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
>> >> > Looks good to me now and also tested with the patches that use
>> >> > these
>> >registers.
>> >> >
>> >> > Reviewed-by: Manasi Navare 
>> >> >
>> >> > Manasi
>> >> >
>> >> > On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
>> >> > > FIXME: This fixes the patch:
>> >>
>> >> "FIXME:" tag is misleading here...
>> >> It looks like  this patch needs to be fixed.
>> >>
>> >> > > Link:
>> >> > > https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-
>> >> > > 2-g it-send-email-anusha.sriva...@intel.com
>> >>
>> >> "Link:" is misleading here... Scripts might think this is the link
>> >> to this patch here...
>> >>
>> >> Please replace these 2 above lines with a direct text that explains
>> >> the issue
>> >>
>> >> Whenever mentioning another commit please use the kernel style:
>> >>
>> >> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.ht
>> >> ml
>> >>
>> >> "If you want to refer to a specific commit, don’t just refer to the
>> >> SHA-1 ID of
>> >the commit. Please also include the oneline summary of the commit, to
>> >make it easier for reviewers to know what it is about"
>> >>
>> >> In this case: commit 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS
>> >> register
>> >> definitions")
>> >
>> >Yes I agree, it should mention the comit ID that is getting fixed.
>> >
>> >>
>> >> > >
>> >> > > Which did not have _MMIO() for DSCA and DSCC.
>> >> > >
>> >> > > v2: Fix typos. (manasi)
>> >>
>> >> Maybe instead of "FIXME:" you wanted the "Fixes:"
>> >>
>> >> In this case please make sure you follow the "Fixes:" rules:
>> >>
>> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.ht
>> >> ml
>> >>
>> >> On this case I'm not 100% confident we want the "Fixes:"
>> >>
>> >> Part of me says no, we don't need Fixes because ICL is on
>> >> alpha_support protection mode, and these patches are just adding
>> >> the definition and not in use yet.
>> >>
>> >> Part of me says yes, we need because I just sent the initial
>> >> patches to 4.19 and Fixme tag would make sure we get this on
>> >> drm-intel-next-fixes still for 4.19. So whatever works use this on
>> >> 4.20 could be easily backported to 4.19 by OSVs...
>> >>
>> >> So, please read the rules and help me to decide. ;)
>> >
>> >May be a good idea to just say in the commit message that it fixes
>> >the reg defs and typos etc.. instead of a formal FIXES tag.
>> Thinking
>> Rodrigo, having FIXES tag is going to help you cherry-pick though, correct?
>
>Yes, if "Fixes:" (non capital) is there, dim scripts will get this patch for 
>drm-intel-
>next-fixes and it will probably be part of 4.19.
>
>Otherwise I won't cherry-pick and it will be only part of 4.20 along with the 
>rest
>of DSC patches.

That is where we want it anyway.

>But have in mind that On a regular fixes flow I'd prefer without the tag so we
>minimize the non-functional-fixes on the flow... After all this is not fixing 
>any real
>4.19 issue. ;)
True.
No tag then 

Thanks for the feedback.

Anusha
>>
>> Anusha
>> >Manasi
>> >
>> >>
>> >> Thanks,
>> >> Rodrigo.
>> >>
>> >> > >
>> >> > > Cc: Rodrigi Vivi 
>> >> > > Cc: Manasi Navare 
>> >> > > Signed-off-by: Anusha Srivatsa 
>> >> > > ---
>> >> > >  drivers/gpu/drm/i915/i915_reg.h | 76
>> >> > > -
>> >> > >  1 file changed, 38 insertions(+), 38 deletions(-)
>> >> > >
>> >> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> >> > > b/drivers/gpu/drm/i915/i915_reg.h index 8af945d..7394605 100644
>> >> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> >> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> >> > > @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>> >> > >  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>> >> > >
>> >> > >  /* Icelake Display Stream Compression Registers */
>> >> > > -#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200
>> >> > > -#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
>> >> > > +#define DSCA_PICTURE_PARAMETER_SET_0
>> >_MMIO(0x6B200)
>> >> > > +#define DSCC_PICTURE_PARAMETER_SET_0
>> >_MMIO(0x6BA00)
>> >> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
>> >> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
>> >> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 

Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 08:28:01PM +, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Friday, July 20, 2018 1:29 PM
> >To: Vivi, Rodrigo 
> >Cc: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS
> >registers
> >
> >On Fri, Jul 20, 2018 at 01:13:07PM -0700, Rodrigo Vivi wrote:
> >> On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
> >> > Looks good to me now and also tested with the patches that use these
> >registers.
> >> >
> >> > Reviewed-by: Manasi Navare 
> >> >
> >> > Manasi
> >> >
> >> > On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> >> > > FIXME: This fixes the patch:
> >>
> >> "FIXME:" tag is misleading here...
> >> It looks like  this patch needs to be fixed.
> >>
> >> > > Link:
> >> > > https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-g
> >> > > it-send-email-anusha.sriva...@intel.com
> >>
> >> "Link:" is misleading here... Scripts might think this is the link to
> >> this patch here...
> >>
> >> Please replace these 2 above lines with a direct text that explains
> >> the issue
> >>
> >> Whenever mentioning another commit please use the kernel style:
> >>
> >> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
> >>
> >> "If you want to refer to a specific commit, don’t just refer to the SHA-1 
> >> ID of
> >the commit. Please also include the oneline summary of the commit, to make it
> >easier for reviewers to know what it is about"
> >>
> >> In this case: commit 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register
> >> definitions")
> >
> >Yes I agree, it should mention the comit ID that is getting fixed.
> >
> >>
> >> > >
> >> > > Which did not have _MMIO() for DSCA and DSCC.
> >> > >
> >> > > v2: Fix typos. (manasi)
> >>
> >> Maybe instead of "FIXME:" you wanted the "Fixes:"
> >>
> >> In this case please make sure you follow the "Fixes:" rules:
> >>
> >> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> >>
> >> On this case I'm not 100% confident we want the "Fixes:"
> >>
> >> Part of me says no, we don't need Fixes because ICL is on
> >> alpha_support protection mode, and these patches are just adding the
> >> definition and not in use yet.
> >>
> >> Part of me says yes, we need because I just sent the initial patches
> >> to 4.19 and Fixme tag would make sure we get this on
> >> drm-intel-next-fixes still for 4.19. So whatever works use this on
> >> 4.20 could be easily backported to 4.19 by OSVs...
> >>
> >> So, please read the rules and help me to decide. ;)
> >
> >May be a good idea to just say in the commit message that it fixes the reg 
> >defs
> >and typos etc.. instead of a formal FIXES tag.
> Thinking
> Rodrigo, having FIXES tag is going to help you cherry-pick though, correct?

Yes, if "Fixes:" (non capital) is there, dim scripts will get this patch
for drm-intel-next-fixes and it will probably be part of 4.19.

Otherwise I won't cherry-pick and it will be only part of 4.20
along with the rest of DSC patches.

But have in mind that On a regular fixes flow I'd prefer without the tag so
we minimize the non-functional-fixes on the flow... After all this is not
fixing any real 4.19 issue. ;)

> 
> Anusha 
> >Manasi
> >
> >>
> >> Thanks,
> >> Rodrigo.
> >>
> >> > >
> >> > > Cc: Rodrigi Vivi 
> >> > > Cc: Manasi Navare 
> >> > > Signed-off-by: Anusha Srivatsa 
> >> > > ---
> >> > >  drivers/gpu/drm/i915/i915_reg.h | 76
> >> > > -
> >> > >  1 file changed, 38 insertions(+), 38 deletions(-)
> >> > >
> >> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> > > b/drivers/gpu/drm/i915/i915_reg.h index 8af945d..7394605 100644
> >> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> >> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> > > @@ -10349,8 +10349,8 @@ enum skl_power_gate {
> >> > >  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN (1 << 23)
> >> > >
> >> > >  /* Icelake Display Stream Compression Registers */
> >> > > -#define DSCA_PICTURE_PARAMETER_SET_0  0x6B200
> >> > > -#define DSCC_PICTURE_PARAMETER_SET_0  0x6BA00
> >> > > +#define DSCA_PICTURE_PARAMETER_SET_0
> > _MMIO(0x6B200)
> >> > > +#define DSCC_PICTURE_PARAMETER_SET_0
> > _MMIO(0x6BA00)
> >> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB  0x78270
> >> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB  0x78370
> >> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC  0x78470
> >> > > @@ -10370,8 +10370,8 @@ enum skl_power_gate {
> >> > >  #define  DSC_VER_MIN_SHIFT4
> >> > >  #define  DSC_VER_MAJ  (0x1 << 0)
> >> > >
> >> > > -#define DSCA_PICTURE_PARAMETER_SET_1  0x6B204
> >> > > -#define DSCC_PICTURE_PARAMETER_SET_1  0x6BA04
> >> > > +#define DSCA_PICTURE_PARAMETER_SET_1
> > _MMIO(0x6B204)
> >> > > +#define DSCC_PICTURE_PARAMETER_SET_1
> > _MMIO(0x6BA04)
> >> > >  #define 

Re: [Intel-gfx] Something is breaking the driver for me

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 06:13:54PM +0200, Jamesie Pic wrote:
>Hello everybody !
>Sorry but I'm really a noob and I got nowhere to turn to.
>I have a lenevo thinkpad x270 on an ultra-dock with 3 external
>monitors:
>00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620
>(rev 02)
>Since last week's updates in Arch linux, I'm having issues with the
>screen in the middle :
>- tearing,
>- full blue or red pixels appear all over the screen,
>- sometimes blanks a few seconds
>This makes it really hard for me to work. I have added
>i915.enable_psr=0, despite the fact that I never needed this, and it's
>a least partly usable, I just have to hang patiently until a bug
>finishes occurring.

well... I'd call this a placebo.

>Any suggestion welcome,
>Best regards

Please file a bug entry following 
https://01.org/linuxgraphics/documentation/how-report-bugs

Please provide all the logs requested there.

thanks,
Rodrigo.

>--
>∞

> ___
> 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] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Srivatsa, Anusha]

>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, July 20, 2018 1:29 PM
>To: Vivi, Rodrigo 
>Cc: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS
>registers
>
>On Fri, Jul 20, 2018 at 01:13:07PM -0700, Rodrigo Vivi wrote:
>> On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
>> > Looks good to me now and also tested with the patches that use these
>registers.
>> >
>> > Reviewed-by: Manasi Navare 
>> >
>> > Manasi
>> >
>> > On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
>> > > FIXME: This fixes the patch:
>>
>> "FIXME:" tag is misleading here...
>> It looks like  this patch needs to be fixed.
>>
>> > > Link:
>> > > https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-g
>> > > it-send-email-anusha.sriva...@intel.com
>>
>> "Link:" is misleading here... Scripts might think this is the link to
>> this patch here...
>>
>> Please replace these 2 above lines with a direct text that explains
>> the issue
>>
>> Whenever mentioning another commit please use the kernel style:
>>
>> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
>>
>> "If you want to refer to a specific commit, don’t just refer to the SHA-1 ID 
>> of
>the commit. Please also include the oneline summary of the commit, to make it
>easier for reviewers to know what it is about"
>>
>> In this case: commit 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register
>> definitions")
>
>Yes I agree, it should mention the comit ID that is getting fixed.
>
>>
>> > >
>> > > Which did not have _MMIO() for DSCA and DSCC.
>> > >
>> > > v2: Fix typos. (manasi)
>>
>> Maybe instead of "FIXME:" you wanted the "Fixes:"
>>
>> In this case please make sure you follow the "Fixes:" rules:
>>
>> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
>>
>> On this case I'm not 100% confident we want the "Fixes:"
>>
>> Part of me says no, we don't need Fixes because ICL is on
>> alpha_support protection mode, and these patches are just adding the
>> definition and not in use yet.
>>
>> Part of me says yes, we need because I just sent the initial patches
>> to 4.19 and Fixme tag would make sure we get this on
>> drm-intel-next-fixes still for 4.19. So whatever works use this on
>> 4.20 could be easily backported to 4.19 by OSVs...
>>
>> So, please read the rules and help me to decide. ;)
>
>May be a good idea to just say in the commit message that it fixes the reg defs
>and typos etc.. instead of a formal FIXES tag.
Thinking
Rodrigo, having FIXES tag is going to help you cherry-pick though, correct?

Anusha 
>Manasi
>
>>
>> Thanks,
>> Rodrigo.
>>
>> > >
>> > > Cc: Rodrigi Vivi 
>> > > Cc: Manasi Navare 
>> > > Signed-off-by: Anusha Srivatsa 
>> > > ---
>> > >  drivers/gpu/drm/i915/i915_reg.h | 76
>> > > -
>> > >  1 file changed, 38 insertions(+), 38 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> > > b/drivers/gpu/drm/i915/i915_reg.h index 8af945d..7394605 100644
>> > > --- a/drivers/gpu/drm/i915/i915_reg.h
>> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
>> > > @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>> > >  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN   (1 << 23)
>> > >
>> > >  /* Icelake Display Stream Compression Registers */
>> > > -#define DSCA_PICTURE_PARAMETER_SET_00x6B200
>> > > -#define DSCC_PICTURE_PARAMETER_SET_00x6BA00
>> > > +#define DSCA_PICTURE_PARAMETER_SET_0
>   _MMIO(0x6B200)
>> > > +#define DSCC_PICTURE_PARAMETER_SET_0
>   _MMIO(0x6BA00)
>> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB0x78270
>> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB0x78370
>> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC0x78470
>> > > @@ -10370,8 +10370,8 @@ enum skl_power_gate {
>> > >  #define  DSC_VER_MIN_SHIFT  4
>> > >  #define  DSC_VER_MAJ(0x1 << 0)
>> > >
>> > > -#define DSCA_PICTURE_PARAMETER_SET_10x6B204
>> > > -#define DSCC_PICTURE_PARAMETER_SET_10x6BA04
>> > > +#define DSCA_PICTURE_PARAMETER_SET_1
>   _MMIO(0x6B204)
>> > > +#define DSCC_PICTURE_PARAMETER_SET_1
>   _MMIO(0x6BA04)
>> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB0x78274
>> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB0x78374
>> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC0x78474
>> > > @@ -10384,8 +10384,8 @@ enum skl_power_gate {
>> > >
>_ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
>> > >  #define  DSC_BPP(bpp)   ((bpp) << 0)
>> > >
>> > > -#define DSCA_PICTURE_PARAMETER_SET_20x6B208
>> > > -#define DSCC_PICTURE_PARAMETER_SET_20x6BA08
>> > > +#define DSCA_PICTURE_PARAMETER_SET_2
>   _MMIO(0x6B208)
>> > > +#define DSCC_PICTURE_PARAMETER_SET_2
>   _MMIO(0x6BA08)
>> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB0x78278
>> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB

Re: [Intel-gfx] [PATCH v6] drm/i915/dp: Limit link training clock recovery loop

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 01:15:59PM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty USB-C MST hubs can
> cause us to get stuck in this loop indefinitely requesting something
> like:
> 
> voltage swing: 0, pre-emphasis level: 2
> voltage swing: 1, pre-emphasis level: 2
> voltage swing: 0, pre-emphasis level: 3
> 
> over and over so max_vswing would never be reached,
> drm_dp_clock_recovery_ok() would never return true and voltage_tries
> would always get reset to 1. The driver sends those values to the hub
> but the hub keeps requesting new values every time.
> 
> Changes in v2:
> - updated commit message (DK, Manasi)
> - defined DP_DP14_MAX_CR_TRIES (Marc)
> - made the loop iterate for max 10 times (Rodrigo, Marc)
> 
> Changes in v3:
> - changed error message to use DP_DP14_MAX_CR_TRIES
> 
> Changes in v4:
> - Updated the title to reflect the change
> - Updated the commit message
> - Added 80 attempts for pre-DP 1.4 devices
> 
> Changes in v5:
> - Removed DP_DP14_MAX_CR_TRIES from drm
> 
> v6: Updated comment to match kernel style (Rodrigo)

thanks... you could've added my rv-b directly as well ;)

> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Cc: Marc Herbert 
> Cc: Manasi Navare 
> Signed-off-by: Nathan Ciobanu 

anyway

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +++--
>  1 file changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 4da6e33c7fa1..299cad5632ed 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  {
>   uint8_t voltage;
> - int voltage_tries, max_vswing_tries;
> + int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
>   uint8_t link_config[2];
>   uint8_t link_bw, rate_select;
>  
> @@ -170,9 +170,20 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   return false;
>   }
>  
> + /*
> +  * DP 1.4 spec clock recovery retries defined but
> +  * for devices pre-DP 1.4 we set the retry limit
> +  * to 4 (voltage levels) x 4 (preemphasis levels) x
> +  * x 5 (same voltage retries) = 80 (max iterations)
> +  */
> + if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> + max_cr_tries = 10;
> + else
> + max_cr_tries = 80;
> +
>   voltage_tries = 1;
>   max_vswing_tries = 0;
> - for (;;) {
> + for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
>  
>   drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> @@ -216,6 +227,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   ++max_vswing_tries;
>  
>   }
> + DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> + return false;
>  }
>  
>  /*
> -- 
> 1.9.1
> 
> ___
> 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] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Manasi Navare]

On Fri, Jul 20, 2018 at 01:13:07PM -0700, Rodrigo Vivi wrote:
> On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
> > Looks good to me now and also tested with the patches that use these 
> > registers.
> > 
> > Reviewed-by: Manasi Navare 
> > 
> > Manasi
> > 
> > On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> > > FIXME: This fixes the patch:
> 
> "FIXME:" tag is misleading here...
> It looks like  this patch needs to be fixed. 
> 
> > > Link: 
> > > https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
> 
> "Link:" is misleading here... Scripts might think this is the link to this
> patch here...
> 
> Please replace these 2 above lines with a direct text that explains the issue
> 
> Whenever mentioning another commit please use the kernel style:
> 
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
> 
> "If you want to refer to a specific commit, don’t just refer to the SHA-1 ID 
> of the commit. Please also include the oneline summary of the commit, to make 
> it easier for reviewers to know what it is about"
> 
> In this case: commit 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register 
> definitions")

Yes I agree, it should mention the comit ID that is getting fixed.

> 
> > > 
> > > Which did not have _MMIO() for DSCA and DSCC.
> > > 
> > > v2: Fix typos. (manasi)
> 
> Maybe instead of "FIXME:" you wanted the "Fixes:"
> 
> In this case please make sure you follow the "Fixes:" rules:
> 
> https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html
> 
> On this case I'm not 100% confident we want the "Fixes:"
> 
> Part of me says no, we don't need Fixes because ICL is on alpha_support
> protection mode, and these patches are just adding the definition and
> not in use yet.
> 
> Part of me says yes, we need because I just sent the initial patches
> to 4.19 and Fixme tag would make sure we get this on drm-intel-next-fixes
> still for 4.19. So whatever works use this on 4.20 could be easily backported
> to 4.19 by OSVs...
> 
> So, please read the rules and help me to decide. ;)

May be a good idea to just say in the commit message that it fixes the reg defs 
and
typos etc.. instead of a formal FIXES tag.

Manasi

> 
> Thanks,
> Rodrigo.
> 
> > > 
> > > Cc: Rodrigi Vivi 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/i915_reg.h | 76 
> > > -
> > >  1 file changed, 38 insertions(+), 38 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 8af945d..7394605 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -10349,8 +10349,8 @@ enum skl_power_gate {
> > >  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
> > >  
> > >  /* Icelake Display Stream Compression Registers */
> > > -#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200
> > > -#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
> > > +#define DSCA_PICTURE_PARAMETER_SET_0 _MMIO(0x6B200)
> > > +#define DSCC_PICTURE_PARAMETER_SET_0 _MMIO(0x6BA00)
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 0x78470
> > > @@ -10370,8 +10370,8 @@ enum skl_power_gate {
> > >  #define  DSC_VER_MIN_SHIFT   4
> > >  #define  DSC_VER_MAJ (0x1 << 0)
> > >  
> > > -#define DSCA_PICTURE_PARAMETER_SET_1 0x6B204
> > > -#define DSCC_PICTURE_PARAMETER_SET_1 0x6BA04
> > > +#define DSCA_PICTURE_PARAMETER_SET_1 _MMIO(0x6B204)
> > > +#define DSCC_PICTURE_PARAMETER_SET_1 _MMIO(0x6BA04)
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB 0x78274
> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB 0x78374
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC 0x78474
> > > @@ -10384,8 +10384,8 @@ enum skl_power_gate {
> > >  
> > > _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
> > >  #define  DSC_BPP(bpp)((bpp) << 0)
> > >  
> > > -#define DSCA_PICTURE_PARAMETER_SET_2 0x6B208
> > > -#define DSCC_PICTURE_PARAMETER_SET_2 0x6BA08
> > > +#define DSCA_PICTURE_PARAMETER_SET_2 _MMIO(0x6B208)
> > > +#define DSCC_PICTURE_PARAMETER_SET_2 _MMIO(0x6BA08)
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB 0x78278
> > >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB 0x78378
> > >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC 0x78478
> > > @@ -10399,8 +10399,8 @@ enum skl_power_gate {
> > >  #define  DSC_PIC_WIDTH(pic_width)((pic_width) << 16)
> > >  #define  DSC_PIC_HEIGHT(pic_height)  ((pic_height) << 0)
> > >  
> > > -#define DSCA_PICTURE_PARAMETER_SET_3 

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/dp: Limit link training clock recovery loop

[Nathan Ciobanu]

On Fri, Jul 20, 2018 at 12:22:15PM -0700, Rodrigo Vivi wrote:
> On Thu, Jul 19, 2018 at 02:47:38PM -0700, Nathan Ciobanu wrote:
> > Limit the link training clock recovery loop to 10 attempts at
> > LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> > pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> > x 5 identical voltages tries). Some faulty USB-C MST hubs can
> > cause us to get stuck in this loop indefinitely requesting something
> > like:
> > 
> > voltage swing: 0, pre-emphasis level: 2
> > voltage swing: 1, pre-emphasis level: 2
> > voltage swing: 0, pre-emphasis level: 3
> > 
> > over and over so max_vswing would never be reached,
> > drm_dp_clock_recovery_ok() would never return true and voltage_tries
> > would always get reset to 1. The driver sends those values to the hub
> > but the hub keeps requesting new values every time.
> > 
> > Changes in v2:
> > - updated commit message (DK, Manasi)
> > - defined DP_DP14_MAX_CR_TRIES (Marc)
> > - made the loop iterate for max 10 times (Rodrigo, Marc)
> > 
> > Changes in v3:
> > - changed error message to use DP_DP14_MAX_CR_TRIES
> > 
> > Changes in v4:
> > - Updated the title to reflect the change
> > - Updated the commit message
> > - Added 80 attempts for pre-DP 1.4 devices
> > 
> > Changes in v5:
> > - Removed DP_DP14_MAX_CR_TRIES from drm
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Cc: Marc Herbert 
> > Cc: Manasi Navare 
> > Signed-off-by: Nathan Ciobanu 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 16 ++--
> >  1 file changed, 14 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 4da6e33c7fa1..7903de7a54c9 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> >  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  {
> > uint8_t voltage;
> > -   int voltage_tries, max_vswing_tries;
> > +   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
> > uint8_t link_config[2];
> > uint8_t link_bw, rate_select;
> >  
> > @@ -170,9 +170,19 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > return false;
> > }
> >  
> > +   /* DP 1.4 spec clock recovery retries defined but
> 
> nip: Preferred kernel multi-line comment is:
> 
> /*
>  * Start comment..
>  * second line..
>  */
> 
> but yeah, I understand we have many precedent cases using the other style...
> 
> Reviewed-by: Rodrigo Vivi 
> (better with comment updated ;))
Absolutely. I made the change and sent the patch again. 
Thanks, Nathan.
> 
> > +* for devices pre-DP 1.4 we set the retry limit
> > +* to 4 (voltage levels) x 4 (preemphasis levels) x
> > +* x 5 (same voltage retries) = 80 (max iterations)
> > +*/
> > +   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> > +   max_cr_tries = 10;
> > +   else
> > +   max_cr_tries = 80;
> > +
> > voltage_tries = 1;
> > max_vswing_tries = 0;
> > -   for (;;) {
> > +   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
> > uint8_t link_status[DP_LINK_STATUS_SIZE];
> >  
> > drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> > @@ -216,6 +226,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > ++max_vswing_tries;
> >  
> > }
> > +   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> > +   return false;
> >  }
> >  
> >  /*
> > -- 
> > 1.9.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v6] drm/i915/dp: Limit link training clock recovery loop

[Nathan Ciobanu]

Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely requesting something
like:

voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage swing: 0, pre-emphasis level: 3

over and over so max_vswing would never be reached,
drm_dp_clock_recovery_ok() would never return true and voltage_tries
would always get reset to 1. The driver sends those values to the hub
but the hub keeps requesting new values every time.

Changes in v2:
- updated commit message (DK, Manasi)
- defined DP_DP14_MAX_CR_TRIES (Marc)
- made the loop iterate for max 10 times (Rodrigo, Marc)

Changes in v3:
- changed error message to use DP_DP14_MAX_CR_TRIES

Changes in v4:
- Updated the title to reflect the change
- Updated the commit message
- Added 80 attempts for pre-DP 1.4 devices

Changes in v5:
- Removed DP_DP14_MAX_CR_TRIES from drm

v6: Updated comment to match kernel style (Rodrigo)

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Cc: Manasi Navare 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 4da6e33c7fa1..299cad5632ed 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries;
+   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -170,9 +170,20 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
+   /*
+* DP 1.4 spec clock recovery retries defined but
+* for devices pre-DP 1.4 we set the retry limit
+* to 4 (voltage levels) x 4 (preemphasis levels) x
+* x 5 (same voltage retries) = 80 (max iterations)
+*/
+   if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
+   max_cr_tries = 10;
+   else
+   max_cr_tries = 80;
+
voltage_tries = 1;
max_vswing_tries = 0;
-   for (;;) {
+   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
@@ -216,6 +227,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
++max_vswing_tries;
 
}
+   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
+   return false;
 }
 
 /*
-- 
1.9.1

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

Re: [Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 11:31:19PM +0200, Marcin Owsiany wrote:
>Hello,
>TL;DR: how can I set a 8960x2880 screen (not display) size on a T580? A
>patch for i915 that I found on the internets does not seem to work.
>Full story:
>I'm a rather happy user of ThinkPad T580 which comes with a
>high-density 3840x2160 LCD, and the following graphics hardware.
>00:02.0 VGA compatible controller: Intel Corporation Device 5917 (rev
>07) (prog-if 00 [VGA controller])
>Subsystem: Lenovo Device 225a
>Flags: bus master, fast devsel, latency 0, IRQ 142
>Memory at e700 (64-bit, non-prefetchable) [size=16M]
>Memory at c000 (64-bit, prefetchable) [size=256M]
>I/O ports at e000 [size=64]
>[virtual] Expansion ROM at 000c [disabled] [size=128K]
>Capabilities: [40] Vendor Specific Information: Len=0c 
>Capabilities: [70] Express Root Complex Integrated Endpoint,
>MSI 00
>Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
>Capabilities: [d0] Power Management version 2
>Capabilities: [100] Process Address Space ID (PASID)
>Capabilities: [200] Address Translation Service (ATS)
>Capabilities: [300] Page Request Interface (PRI)
>Kernel driver in use: i915
>Kernel modules: i915
>Unfortunately attaching it to an external normal-density 2560x1440
>display means I need to apply scaling. Combined with the side-by-side
>arrangement of monitors, this means I'd need to set screen size
>to 8960x2880. However this does not work:
> $ xrandr --fb 8960x2880
> xrandr: screen cannot be larger than 8192x8192 (desired size
>8960x2880)
>I found this [1]thread on reddit about the same problem, where a user
>posted a simple patch claimed to be supplied by someone on #intel-gfx.
>Unfortunately it does not work (or at least is not sufficient) - after
>applying it xrandr does claim that 16384x16384 is possible, but
>actually trying to use more than 8192x8192 fails with an error
>(unfortunately I lost the exact message).

I'm afraid that it is a hardware limitation that you won't be able to
workaround. But a log would be interesting anyway... (both dmesg and xorg.0.log)

>My current workaround is to pretend that the displays are arranged
>vertically, but even after a few months I'm sometimes having trouble
>remembering that I need to move mouse cursor UP when I want to go to
>LEFT display :-)

This is another bug And probably the right (only?) fixable fr your
setup.

>I wonder if someone could help me here. Even just getting a definite
>answer on whether my hardware can in theory support this or not would
>be helpful, since I found conflicting information.

Well, I'm afraid the right information is already there on the first
xrandr output. The rest was just misleading you.

>FWIW I'm on Debian stable, Linux 4.9.8x.
>regards,
>Marcin
> 
> References
> 
>1. 
> https://www.reddit.com/r/linux/comments/6bghzm/increasing_maximum_xorg_virtual_screen_resolution/

> ___
> 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] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 12:25:47PM -0700, Manasi Navare wrote:
> Looks good to me now and also tested with the patches that use these 
> registers.
> 
> Reviewed-by: Manasi Navare 
> 
> Manasi
> 
> On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> > FIXME: This fixes the patch:

"FIXME:" tag is misleading here...
It looks like  this patch needs to be fixed. 

> > Link: 
> > https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com

"Link:" is misleading here... Scripts might think this is the link to this
patch here...

Please replace these 2 above lines with a direct text that explains the issue

Whenever mentioning another commit please use the kernel style:

https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html

"If you want to refer to a specific commit, don’t just refer to the SHA-1 ID of 
the commit. Please also include the oneline summary of the commit, to make it 
easier for reviewers to know what it is about"

In this case: commit 2efbb2f099fb ("i915/dp/dsc: Add DSC PPS register 
definitions")

> > 
> > Which did not have _MMIO() for DSCA and DSCC.
> > 
> > v2: Fix typos. (manasi)

Maybe instead of "FIXME:" you wanted the "Fixes:"

In this case please make sure you follow the "Fixes:" rules:

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html

On this case I'm not 100% confident we want the "Fixes:"

Part of me says no, we don't need Fixes because ICL is on alpha_support
protection mode, and these patches are just adding the definition and
not in use yet.

Part of me says yes, we need because I just sent the initial patches
to 4.19 and Fixme tag would make sure we get this on drm-intel-next-fixes
still for 4.19. So whatever works use this on 4.20 could be easily backported
to 4.19 by OSVs...

So, please read the rules and help me to decide. ;)

Thanks,
Rodrigo.

> > 
> > Cc: Rodrigi Vivi 
> > Cc: Manasi Navare 
> > Signed-off-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h | 76 
> > -
> >  1 file changed, 38 insertions(+), 38 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h 
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 8af945d..7394605 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -10349,8 +10349,8 @@ enum skl_power_gate {
> >  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
> >  
> >  /* Icelake Display Stream Compression Registers */
> > -#define DSCA_PICTURE_PARAMETER_SET_0   0x6B200
> > -#define DSCC_PICTURE_PARAMETER_SET_0   0x6BA00
> > +#define DSCA_PICTURE_PARAMETER_SET_0   _MMIO(0x6B200)
> > +#define DSCC_PICTURE_PARAMETER_SET_0   _MMIO(0x6BA00)
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB   0x78270
> >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB   0x78370
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC   0x78470
> > @@ -10370,8 +10370,8 @@ enum skl_power_gate {
> >  #define  DSC_VER_MIN_SHIFT 4
> >  #define  DSC_VER_MAJ   (0x1 << 0)
> >  
> > -#define DSCA_PICTURE_PARAMETER_SET_1   0x6B204
> > -#define DSCC_PICTURE_PARAMETER_SET_1   0x6BA04
> > +#define DSCA_PICTURE_PARAMETER_SET_1   _MMIO(0x6B204)
> > +#define DSCC_PICTURE_PARAMETER_SET_1   _MMIO(0x6BA04)
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB   0x78274
> >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB   0x78374
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC   0x78474
> > @@ -10384,8 +10384,8 @@ enum skl_power_gate {
> >
> > _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
> >  #define  DSC_BPP(bpp)  ((bpp) << 0)
> >  
> > -#define DSCA_PICTURE_PARAMETER_SET_2   0x6B208
> > -#define DSCC_PICTURE_PARAMETER_SET_2   0x6BA08
> > +#define DSCA_PICTURE_PARAMETER_SET_2   _MMIO(0x6B208)
> > +#define DSCC_PICTURE_PARAMETER_SET_2   _MMIO(0x6BA08)
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB   0x78278
> >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB   0x78378
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC   0x78478
> > @@ -10399,8 +10399,8 @@ enum skl_power_gate {
> >  #define  DSC_PIC_WIDTH(pic_width)  ((pic_width) << 16)
> >  #define  DSC_PIC_HEIGHT(pic_height)((pic_height) << 0)
> >  
> > -#define DSCA_PICTURE_PARAMETER_SET_3   0x6B20C
> > -#define DSCC_PICTURE_PARAMETER_SET_3   0x6BA0C
> > +#define DSCA_PICTURE_PARAMETER_SET_3   _MMIO(0x6B20C)
> > +#define DSCC_PICTURE_PARAMETER_SET_3   _MMIO(0x6BA0C)
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB   0x7827C
> >  #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB   0x7837C
> >  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC   0x7847C
> > @@ -10414,8 +10414,8 @@ enum skl_power_gate {
> >  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dsc: Add missing _MMIO() from PPS registers (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/dsc: Add missing _MMIO() from PPS registers (rev2)
URL   : https://patchwork.freedesktop.org/series/46979/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9739 =

== Summary - WARNING ==

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

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@drv_selftest@live_guc:
  fi-skl-6260u:   PASS -> SKIP +1
  fi-kbl-7560u:   PASS -> SKIP +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7560u:   PASS -> DMESG-FAIL (fdo#106947)
  fi-skl-6260u:   PASS -> DMESG-FAIL (fdo#106560)


 Possible fixes 

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

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


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


== Participating hosts (47 -> 41) ==

  Missing(6): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks 
fi-bsw-cyan fi-ctg-p8600 


== Build changes ==

* Linux: CI_DRM_4521 -> Patchwork_9739

  CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4570: 65cdccdc7bcbb791d791acb784a382110a3c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9739: 95020adeaf31a8d1359fea572ddb6fb86da13fd2 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

95020adeaf31 drm/i915/dsc: Add missing _MMIO() from PPS registers

== Logs ==

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

Re: [Intel-gfx] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Manasi Navare]

Looks good to me now and also tested with the patches that use these registers.

Reviewed-by: Manasi Navare 

Manasi

On Fri, Jul 20, 2018 at 12:10:39PM -0700, Anusha Srivatsa wrote:
> FIXME: This fixes the patch:
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
> 
> Which did not have _MMIO() for DSCA and DSCC.
> 
> v2: Fix typos. (manasi)
> 
> Cc: Rodrigi Vivi 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 76 
> -
>  1 file changed, 38 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8af945d..7394605 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>  
>  /* Icelake Display Stream Compression Registers */
> -#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200
> -#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
> +#define DSCA_PICTURE_PARAMETER_SET_0 _MMIO(0x6B200)
> +#define DSCC_PICTURE_PARAMETER_SET_0 _MMIO(0x6BA00)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 0x78470
> @@ -10370,8 +10370,8 @@ enum skl_power_gate {
>  #define  DSC_VER_MIN_SHIFT   4
>  #define  DSC_VER_MAJ (0x1 << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_1 0x6B204
> -#define DSCC_PICTURE_PARAMETER_SET_1 0x6BA04
> +#define DSCA_PICTURE_PARAMETER_SET_1 _MMIO(0x6B204)
> +#define DSCC_PICTURE_PARAMETER_SET_1 _MMIO(0x6BA04)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB 0x78274
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB 0x78374
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC 0x78474
> @@ -10384,8 +10384,8 @@ enum skl_power_gate {
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
>  #define  DSC_BPP(bpp)((bpp) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_2 0x6B208
> -#define DSCC_PICTURE_PARAMETER_SET_2 0x6BA08
> +#define DSCA_PICTURE_PARAMETER_SET_2 _MMIO(0x6B208)
> +#define DSCC_PICTURE_PARAMETER_SET_2 _MMIO(0x6BA08)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB 0x78278
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB 0x78378
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC 0x78478
> @@ -10399,8 +10399,8 @@ enum skl_power_gate {
>  #define  DSC_PIC_WIDTH(pic_width)((pic_width) << 16)
>  #define  DSC_PIC_HEIGHT(pic_height)  ((pic_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_3 0x6B20C
> -#define DSCC_PICTURE_PARAMETER_SET_3 0x6BA0C
> +#define DSCA_PICTURE_PARAMETER_SET_3 _MMIO(0x6B20C)
> +#define DSCC_PICTURE_PARAMETER_SET_3 _MMIO(0x6BA0C)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB 0x7827C
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB 0x7837C
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC 0x7847C
> @@ -10414,8 +10414,8 @@ enum skl_power_gate {
>  #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
>  #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_4 0x6B210
> -#define DSCC_PICTURE_PARAMETER_SET_4 0x6BA10
> +#define DSCA_PICTURE_PARAMETER_SET_4 _MMIO(0x6B210)
> +#define DSCC_PICTURE_PARAMETER_SET_4 _MMIO(0x6BA10)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB 0x78280
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB 0x78380
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC 0x78480
> @@ -10429,8 +10429,8 @@ enum skl_power_gate {
>  #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
>  #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_5 0x6B214
> -#define DSCC_PICTURE_PARAMETER_SET_5 0x6BA14
> +#define DSCA_PICTURE_PARAMETER_SET_5 _MMIO(0x6B214)
> +#define DSCC_PICTURE_PARAMETER_SET_5 _MMIO(0x6BA14)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB 0x78284
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB 0x78384
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC 0x78484
> @@ -10441,11 +10441,11 @@ enum skl_power_gate {
>  #define ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe)   _MMIO_PIPE((pipe) - 
> PIPE_B, \
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_5_PC, \
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_5_PC)
> -#define  DSC_SCALE_DEC_INTINT(scale_dec) ((scale_dec) << 16)
> +#define  DSC_SCALE_DEC_INT(scale_dec)((scale_dec) << 16)
>  #define  DSC_SCALE_INC_INT(scale_inc)((scale_inc) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_6 0x6B218
> -#define DSCC_PICTURE_PARAMETER_SET_6 

Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/dp: Limit link training clock recovery loop

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 02:47:38PM -0700, Nathan Ciobanu wrote:
> Limit the link training clock recovery loop to 10 attempts at
> LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
> pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
> x 5 identical voltages tries). Some faulty USB-C MST hubs can
> cause us to get stuck in this loop indefinitely requesting something
> like:
> 
> voltage swing: 0, pre-emphasis level: 2
> voltage swing: 1, pre-emphasis level: 2
> voltage swing: 0, pre-emphasis level: 3
> 
> over and over so max_vswing would never be reached,
> drm_dp_clock_recovery_ok() would never return true and voltage_tries
> would always get reset to 1. The driver sends those values to the hub
> but the hub keeps requesting new values every time.
> 
> Changes in v2:
> - updated commit message (DK, Manasi)
> - defined DP_DP14_MAX_CR_TRIES (Marc)
> - made the loop iterate for max 10 times (Rodrigo, Marc)
> 
> Changes in v3:
> - changed error message to use DP_DP14_MAX_CR_TRIES
> 
> Changes in v4:
> - Updated the title to reflect the change
> - Updated the commit message
> - Added 80 attempts for pre-DP 1.4 devices
> 
> Changes in v5:
> - Removed DP_DP14_MAX_CR_TRIES from drm
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Cc: Marc Herbert 
> Cc: Manasi Navare 
> Signed-off-by: Nathan Ciobanu 
> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 16 ++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 4da6e33c7fa1..7903de7a54c9 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -129,7 +129,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  {
>   uint8_t voltage;
> - int voltage_tries, max_vswing_tries;
> + int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
>   uint8_t link_config[2];
>   uint8_t link_bw, rate_select;
>  
> @@ -170,9 +170,19 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   return false;
>   }
>  
> + /* DP 1.4 spec clock recovery retries defined but

nip: Preferred kernel multi-line comment is:

/*
 * Start comment..
 * second line..
 */

but yeah, I understand we have many precedent cases using the other style...

Reviewed-by: Rodrigo Vivi 
(better with comment updated ;))

> +  * for devices pre-DP 1.4 we set the retry limit
> +  * to 4 (voltage levels) x 4 (preemphasis levels) x
> +  * x 5 (same voltage retries) = 80 (max iterations)
> +  */
> + if (intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> + max_cr_tries = 10;
> + else
> + max_cr_tries = 80;
> +
>   voltage_tries = 1;
>   max_vswing_tries = 0;
> - for (;;) {
> + for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
>  
>   drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> @@ -216,6 +226,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   ++max_vswing_tries;
>  
>   }
> + DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> + return false;
>  }
>  
>  /*
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show debugfs dpcd read failure directly

[Patchwork]

== Series Details ==

Series: drm/i915: Show debugfs dpcd read failure directly
URL   : https://patchwork.freedesktop.org/series/46977/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9737 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-kbl-7500u:   PASS -> DMESG-FAIL (fdo#106947, fdo#106560)

igt@kms_chamelium@hdmi-hpd-fast:
  fi-kbl-7500u:   SKIP -> FAIL (fdo#102672, fdo#103841)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

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

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  fdo#102672 https://bugs.freedesktop.org/show_bug.cgi?id=102672
  fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713
  fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#106947 https://bugs.freedesktop.org/show_bug.cgi?id=106947


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4521 -> Patchwork_9737

  CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4570: 65cdccdc7bcbb791d791acb784a382110a3c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9737: 84fb667b4f2eaba40302eaa18d7ca1297008d07c @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

84fb667b4f2e drm/i915: Show debugfs dpcd read failure directly

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v5] drm/i915/dp: Refactor max_vswing_tries variable (rev3)

[Patchwork]

== Series Details ==

Series: series starting with [v5] drm/i915/dp: Refactor max_vswing_tries 
variable (rev3)
URL   : https://patchwork.freedesktop.org/series/46897/
State : failure

== Summary ==

Applying: drm/i915/dp: Refactor max_vswing_tries variable
error: sha1 information is lacking or useless 
(drivers/gpu/drm/i915/intel_dp_link_training.c).
error: could not build fake ancestor
Patch failed at 0001 drm/i915/dp: Refactor max_vswing_tries variable
Use 'git am --show-current-patch' to see the failed 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] [v2] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Anusha Srivatsa]

FIXME: This fixes the patch:
Link: 
https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com

Which did not have _MMIO() for DSCA and DSCC.

v2: Fix typos. (manasi)

Cc: Rodrigi Vivi 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h | 76 -
 1 file changed, 38 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8af945d..7394605 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10349,8 +10349,8 @@ enum skl_power_gate {
 #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
 
 /* Icelake Display Stream Compression Registers */
-#define DSCA_PICTURE_PARAMETER_SET_0   0x6B200
-#define DSCC_PICTURE_PARAMETER_SET_0   0x6BA00
+#define DSCA_PICTURE_PARAMETER_SET_0   _MMIO(0x6B200)
+#define DSCC_PICTURE_PARAMETER_SET_0   _MMIO(0x6BA00)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB   0x78270
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB   0x78370
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC   0x78470
@@ -10370,8 +10370,8 @@ enum skl_power_gate {
 #define  DSC_VER_MIN_SHIFT 4
 #define  DSC_VER_MAJ   (0x1 << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_1   0x6B204
-#define DSCC_PICTURE_PARAMETER_SET_1   0x6BA04
+#define DSCA_PICTURE_PARAMETER_SET_1   _MMIO(0x6B204)
+#define DSCC_PICTURE_PARAMETER_SET_1   _MMIO(0x6BA04)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB   0x78274
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB   0x78374
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC   0x78474
@@ -10384,8 +10384,8 @@ enum skl_power_gate {
   
_ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
 #define  DSC_BPP(bpp)  ((bpp) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_2   0x6B208
-#define DSCC_PICTURE_PARAMETER_SET_2   0x6BA08
+#define DSCA_PICTURE_PARAMETER_SET_2   _MMIO(0x6B208)
+#define DSCC_PICTURE_PARAMETER_SET_2   _MMIO(0x6BA08)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB   0x78278
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB   0x78378
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC   0x78478
@@ -10399,8 +10399,8 @@ enum skl_power_gate {
 #define  DSC_PIC_WIDTH(pic_width)  ((pic_width) << 16)
 #define  DSC_PIC_HEIGHT(pic_height)((pic_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_3   0x6B20C
-#define DSCC_PICTURE_PARAMETER_SET_3   0x6BA0C
+#define DSCA_PICTURE_PARAMETER_SET_3   _MMIO(0x6B20C)
+#define DSCC_PICTURE_PARAMETER_SET_3   _MMIO(0x6BA0C)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB   0x7827C
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB   0x7837C
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC   0x7847C
@@ -10414,8 +10414,8 @@ enum skl_power_gate {
 #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
 #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_4   0x6B210
-#define DSCC_PICTURE_PARAMETER_SET_4   0x6BA10
+#define DSCA_PICTURE_PARAMETER_SET_4   _MMIO(0x6B210)
+#define DSCC_PICTURE_PARAMETER_SET_4   _MMIO(0x6BA10)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB   0x78280
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB   0x78380
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC   0x78480
@@ -10429,8 +10429,8 @@ enum skl_power_gate {
 #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
 #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_5   0x6B214
-#define DSCC_PICTURE_PARAMETER_SET_5   0x6BA14
+#define DSCA_PICTURE_PARAMETER_SET_5   _MMIO(0x6B214)
+#define DSCC_PICTURE_PARAMETER_SET_5   _MMIO(0x6BA14)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB   0x78284
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB   0x78384
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC   0x78484
@@ -10441,11 +10441,11 @@ enum skl_power_gate {
 #define ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe) _MMIO_PIPE((pipe) - PIPE_B, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_5_PC, \
   
_ICL_DSC1_PICTURE_PARAMETER_SET_5_PC)
-#define  DSC_SCALE_DEC_INTINT(scale_dec)   ((scale_dec) << 16)
+#define  DSC_SCALE_DEC_INT(scale_dec)  ((scale_dec) << 16)
 #define  DSC_SCALE_INC_INT(scale_inc)  ((scale_inc) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_6   0x6B218
-#define DSCC_PICTURE_PARAMETER_SET_6   0x6BA18
+#define DSCA_PICTURE_PARAMETER_SET_6   _MMIO(0x6B218)
+#define DSCC_PICTURE_PARAMETER_SET_6   _MMIO(0x6BA18)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PB   0x78288
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_6_PB   0x78388
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PC   

Re: [Intel-gfx] [PATCH v5] drm/i915/dp: Refactor max_vswing_tries variable

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 11:23:43AM -0700, Nathan Ciobanu wrote:
> Changes the type and renames the max_vswing_tries variable
> which was declared as an integer but used as a boolean
> making it easy to be confused with a counter.
> 
> Changes in v2:
> - updated the title and commit message
> - left the loop exit point in place
> 
> v3: fix typo in title
> v4: renamed max_vswing to max_vswing_reached (Ville)
> 
> Cc: Dhinakaran Pandiyan 
> Cc: Rodrigo Vivi 
> Cc: Marc Herbert 
> Signed-off-by: Nathan Ciobanu 

Reviewed-by: Rodrigo Vivi 

> ---
>  drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 7903de7a54c9..0d418f5a59b0 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -129,7 +129,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
>  {
>   uint8_t voltage;
> - int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
> + int voltage_tries, cr_tries, max_cr_tries;
> + bool max_vswing_reached = false;
>   uint8_t link_config[2];
>   uint8_t link_bw, rate_select;
>  
> @@ -181,7 +182,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   max_cr_tries = 80;
>  
>   voltage_tries = 1;
> - max_vswing_tries = 0;
>   for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
>   uint8_t link_status[DP_LINK_STATUS_SIZE];
>  
> @@ -202,7 +202,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   return false;
>   }
>  
> - if (max_vswing_tries == 1) {
> + if (max_vswing_reached) {
>   DRM_DEBUG_KMS("Max Voltage Swing reached\n");
>   return false;
>   }
> @@ -223,7 +223,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> intel_dp *intel_dp)
>   voltage_tries = 1;
>  
>   if (intel_dp_link_max_vswing_reached(intel_dp))
> - ++max_vswing_tries;
> + max_vswing_reached = true;
>  
>   }
>   DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> -- 
> 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/dsc: Add missing _MMIO() from PPS registers

[Manasi Navare]

There are more typos in this patch as below that need to be fixed:


On Fri, Jul 20, 2018 at 11:04:38AM -0700, Anusha Srivatsa wrote:
> FIXME: This fixes the patch:
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com
> 
> Which did not have _MMIO() for DSCA and DSCC.
> 
> Cc: Rodrigi Vivi 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 68 
> -
>  1 file changed, 34 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8af945d..1345e83 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -10349,8 +10349,8 @@ enum skl_power_gate {
>  #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>  
>  /* Icelake Display Stream Compression Registers */
> -#define DSCA_PICTURE_PARAMETER_SET_0 0x6B200
> -#define DSCC_PICTURE_PARAMETER_SET_0 0x6BA00
> +#define DSCA_PICTURE_PARAMETER_SET_0 _MMIO(0x6B200)
> +#define DSCC_PICTURE_PARAMETER_SET_0 _MMIO(0x6BA00)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB 0x78270
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB 0x78370
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC 0x78470
> @@ -10370,8 +10370,8 @@ enum skl_power_gate {
>  #define  DSC_VER_MIN_SHIFT   4
>  #define  DSC_VER_MAJ (0x1 << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_1 0x6B204
> -#define DSCC_PICTURE_PARAMETER_SET_1 0x6BA04
> +#define DSCA_PICTURE_PARAMETER_SET_1 _MMIO(0x6B204)
> +#define DSCC_PICTURE_PARAMETER_SET_1 _MMIO(0x6BA04)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB 0x78274
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB 0x78374
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC 0x78474
> @@ -10384,8 +10384,8 @@ enum skl_power_gate {
>  
> _ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
>  #define  DSC_BPP(bpp)((bpp) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_2 0x6B208
> -#define DSCC_PICTURE_PARAMETER_SET_2 0x6BA08
> +#define DSCA_PICTURE_PARAMETER_SET_2 _MMIO(0x6B208)
> +#define DSCC_PICTURE_PARAMETER_SET_2 _MMIO(0x6BA08)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB 0x78278
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB 0x78378
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC 0x78478
> @@ -10399,8 +10399,8 @@ enum skl_power_gate {
>  #define  DSC_PIC_WIDTH(pic_width)((pic_width) << 16)
>  #define  DSC_PIC_HEIGHT(pic_height)  ((pic_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_3 0x6B20C
> -#define DSCC_PICTURE_PARAMETER_SET_3 0x6BA0C
> +#define DSCA_PICTURE_PARAMETER_SET_3 _MMIO(0x6B20C)
> +#define DSCC_PICTURE_PARAMETER_SET_3 _MMIO(0x6BA0C)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB 0x7827C
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB 0x7837C
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC 0x7847C
> @@ -10414,8 +10414,8 @@ enum skl_power_gate {
>  #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
>  #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_4 0x6B210
> -#define DSCC_PICTURE_PARAMETER_SET_4 0x6BA10
> +#define DSCA_PICTURE_PARAMETER_SET_4 _MMIO(0x6B210)
> +#define DSCC_PICTURE_PARAMETER_SET_4 _MMIO(0x6BA10)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB 0x78280
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB 0x78380
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC 0x78480
> @@ -10429,8 +10429,8 @@ enum skl_power_gate {
>  #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
>  #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_5 0x6B214
> -#define DSCC_PICTURE_PARAMETER_SET_5 0x6BA14
> +#define DSCA_PICTURE_PARAMETER_SET_5 _MMIO(0x6B214)
> +#define DSCC_PICTURE_PARAMETER_SET_5 _MMIO(0x6BA14)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB 0x78284
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB 0x78384
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC 0x78484
> @@ -10444,8 +10444,8 @@ enum skl_power_gate {
>  #define  DSC_SCALE_DEC_INTINT(scale_dec) ((scale_dec) << 16)

DSC_SCALE_DEC_INT

>  #define  DSC_SCALE_INC_INT(scale_inc)((scale_inc) << 0)
>  
> -#define DSCA_PICTURE_PARAMETER_SET_6 0x6B218
> -#define DSCC_PICTURE_PARAMETER_SET_6 0x6BA18
> +#define DSCA_PICTURE_PARAMETER_SET_6 _MMIO(0x6B218)
> +#define DSCC_PICTURE_PARAMETER_SET_6 _MMIO(0x6BA18)
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PB 0x78288
>  #define _ICL_DSC1_PICTURE_PARAMETER_SET_6_PB 0x78388
>  #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PC 0x78488

For PPS6, correct the RHS of this define to use max_qp and min_qp:
#define  DSC_FLATNESS_MAX_QP(max_qp) 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp: add extended receiver capability field present bit

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/dp: add extended receiver capability 
field present bit
URL   : https://patchwork.freedesktop.org/series/46965/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4521 -> Patchwork_9736 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: PASS -> DMESG-FAIL (fdo#107174)

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)


 Possible fixes 

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


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

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


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4521 -> Patchwork_9736

  CI_DRM_4521: a4ebbd84c682fd30edbde6ac0e48d150d4c5c066 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4570: 65cdccdc7bcbb791d791acb784a382110a3c @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9736: d20291854091a3f766dd98b37460faf57ef2b30e @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

d20291854091 drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT
f12f0082792a drm/dp: add extended receiver capability field present bit

== Logs ==

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

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dp: Refactor mav_vswing_tries variable

[Nathan Ciobanu]

On Fri, Jul 20, 2018 at 01:19:02PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 19, 2018 at 02:48:07PM -0700, Nathan Ciobanu wrote:
> > Changes the type and renames the max_vswing_tries variable
> > which was declared as an integer but used as a boolean
> > making it easy to be confused with a counter.
> > 
> > Changes in v2:
> > - updated the title and commit message
> > - left the loop exit point in place
> > 
> > Cc: Dhinakaran Pandiyan 
> > Cc: Rodrigo Vivi 
> > Cc: Marc Herbert 
> > Signed-off-by: Nathan Ciobanu 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 7903de7a54c9..ec5f2bb55c9a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -129,7 +129,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> >  intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
> >  {
> > uint8_t voltage;
> > -   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
> > +   int voltage_tries, cr_tries, max_cr_tries;
> > +   bool max_vswing = false;
> 
> max_vswing_reached?
Ok, I renamed it and resent the patch. Thanks,
Nathan
> 
> > uint8_t link_config[2];
> > uint8_t link_bw, rate_select;
> >  
> > @@ -181,7 +182,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > max_cr_tries = 80;
> >  
> > voltage_tries = 1;
> > -   max_vswing_tries = 0;
> > for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
> > uint8_t link_status[DP_LINK_STATUS_SIZE];
> >  
> > @@ -202,7 +202,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > return false;
> > }
> >  
> > -   if (max_vswing_tries == 1) {
> > +   if (max_vswing) {
> > DRM_DEBUG_KMS("Max Voltage Swing reached\n");
> > return false;
> > }
> > @@ -223,7 +223,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
> > intel_dp *intel_dp)
> > voltage_tries = 1;
> >  
> > if (intel_dp_link_max_vswing_reached(intel_dp))
> > -   ++max_vswing_tries;
> > +   max_vswing = true;
> >  
> > }
> > DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
> > -- 
> > 1.9.1
> > 
> > ___
> > 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

[Intel-gfx] [PATCH v5] drm/i915/dp: Refactor max_vswing_tries variable

[Nathan Ciobanu]

Changes the type and renames the max_vswing_tries variable
which was declared as an integer but used as a boolean
making it easy to be confused with a counter.

Changes in v2:
- updated the title and commit message
- left the loop exit point in place

v3: fix typo in title
v4: renamed max_vswing to max_vswing_reached (Ville)

Cc: Dhinakaran Pandiyan 
Cc: Rodrigo Vivi 
Cc: Marc Herbert 
Signed-off-by: Nathan Ciobanu 
---
 drivers/gpu/drm/i915/intel_dp_link_training.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 7903de7a54c9..0d418f5a59b0 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -129,7 +129,8 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
 intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp)
 {
uint8_t voltage;
-   int voltage_tries, max_vswing_tries, cr_tries, max_cr_tries;
+   int voltage_tries, cr_tries, max_cr_tries;
+   bool max_vswing_reached = false;
uint8_t link_config[2];
uint8_t link_bw, rate_select;
 
@@ -181,7 +182,6 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
max_cr_tries = 80;
 
voltage_tries = 1;
-   max_vswing_tries = 0;
for (cr_tries = 0; cr_tries < max_cr_tries; ++cr_tries) {
uint8_t link_status[DP_LINK_STATUS_SIZE];
 
@@ -202,7 +202,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
return false;
}
 
-   if (max_vswing_tries == 1) {
+   if (max_vswing_reached) {
DRM_DEBUG_KMS("Max Voltage Swing reached\n");
return false;
}
@@ -223,7 +223,7 @@ static bool intel_dp_link_max_vswing_reached(struct 
intel_dp *intel_dp)
voltage_tries = 1;
 
if (intel_dp_link_max_vswing_reached(intel_dp))
-   ++max_vswing_tries;
+   max_vswing_reached = true;
 
}
DRM_ERROR("Failed clock recovery %d times, giving up!\n", max_cr_tries);
-- 
1.9.1

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

[Intel-gfx] [PATCH] drm/i915/dsc: Add missing _MMIO() from PPS registers

[Anusha Srivatsa]

FIXME: This fixes the patch:
Link: 
https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.sriva...@intel.com

Which did not have _MMIO() for DSCA and DSCC.

Cc: Rodrigi Vivi 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h | 68 -
 1 file changed, 34 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8af945d..1345e83 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -10349,8 +10349,8 @@ enum skl_power_gate {
 #define  ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN  (1 << 23)
 
 /* Icelake Display Stream Compression Registers */
-#define DSCA_PICTURE_PARAMETER_SET_0   0x6B200
-#define DSCC_PICTURE_PARAMETER_SET_0   0x6BA00
+#define DSCA_PICTURE_PARAMETER_SET_0   _MMIO(0x6B200)
+#define DSCC_PICTURE_PARAMETER_SET_0   _MMIO(0x6BA00)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PB   0x78270
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_0_PB   0x78370
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_0_PC   0x78470
@@ -10370,8 +10370,8 @@ enum skl_power_gate {
 #define  DSC_VER_MIN_SHIFT 4
 #define  DSC_VER_MAJ   (0x1 << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_1   0x6B204
-#define DSCC_PICTURE_PARAMETER_SET_1   0x6BA04
+#define DSCA_PICTURE_PARAMETER_SET_1   _MMIO(0x6B204)
+#define DSCC_PICTURE_PARAMETER_SET_1   _MMIO(0x6BA04)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PB   0x78274
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_1_PB   0x78374
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_1_PC   0x78474
@@ -10384,8 +10384,8 @@ enum skl_power_gate {
   
_ICL_DSC1_PICTURE_PARAMETER_SET_1_PC)
 #define  DSC_BPP(bpp)  ((bpp) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_2   0x6B208
-#define DSCC_PICTURE_PARAMETER_SET_2   0x6BA08
+#define DSCA_PICTURE_PARAMETER_SET_2   _MMIO(0x6B208)
+#define DSCC_PICTURE_PARAMETER_SET_2   _MMIO(0x6BA08)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PB   0x78278
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_2_PB   0x78378
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_2_PC   0x78478
@@ -10399,8 +10399,8 @@ enum skl_power_gate {
 #define  DSC_PIC_WIDTH(pic_width)  ((pic_width) << 16)
 #define  DSC_PIC_HEIGHT(pic_height)((pic_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_3   0x6B20C
-#define DSCC_PICTURE_PARAMETER_SET_3   0x6BA0C
+#define DSCA_PICTURE_PARAMETER_SET_3   _MMIO(0x6B20C)
+#define DSCC_PICTURE_PARAMETER_SET_3   _MMIO(0x6BA0C)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PB   0x7827C
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_3_PB   0x7837C
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_3_PC   0x7847C
@@ -10414,8 +10414,8 @@ enum skl_power_gate {
 #define  DSC_SLICE_WIDTH(slice_width)   ((slice_width) << 16)
 #define  DSC_SLICE_HEIGHT(slice_height) ((slice_height) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_4   0x6B210
-#define DSCC_PICTURE_PARAMETER_SET_4   0x6BA10
+#define DSCA_PICTURE_PARAMETER_SET_4   _MMIO(0x6B210)
+#define DSCC_PICTURE_PARAMETER_SET_4   _MMIO(0x6BA10)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PB   0x78280
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_4_PB   0x78380
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_4_PC   0x78480
@@ -10429,8 +10429,8 @@ enum skl_power_gate {
 #define  DSC_INITIAL_DEC_DELAY(dec_delay)   ((dec_delay) << 16)
 #define  DSC_INITIAL_XMIT_DELAY(xmit_delay) ((xmit_delay) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_5   0x6B214
-#define DSCC_PICTURE_PARAMETER_SET_5   0x6BA14
+#define DSCA_PICTURE_PARAMETER_SET_5   _MMIO(0x6B214)
+#define DSCC_PICTURE_PARAMETER_SET_5   _MMIO(0x6BA14)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PB   0x78284
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_5_PB   0x78384
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_5_PC   0x78484
@@ -10444,8 +10444,8 @@ enum skl_power_gate {
 #define  DSC_SCALE_DEC_INTINT(scale_dec)   ((scale_dec) << 16)
 #define  DSC_SCALE_INC_INT(scale_inc)  ((scale_inc) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_6   0x6B218
-#define DSCC_PICTURE_PARAMETER_SET_6   0x6BA18
+#define DSCA_PICTURE_PARAMETER_SET_6   _MMIO(0x6B218)
+#define DSCC_PICTURE_PARAMETER_SET_6   _MMIO(0x6BA18)
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PB   0x78288
 #define _ICL_DSC1_PICTURE_PARAMETER_SET_6_PB   0x78388
 #define _ICL_DSC0_PICTURE_PARAMETER_SET_6_PC   0x78488
@@ -10461,8 +10461,8 @@ enum skl_power_gate {
 #define  DSC_FIRST_LINE_BPG_OFFSET(offset) ((offset) << 8)
 #define  DSC_INITIAL_SCALE_VALUE(value)((value) << 0)
 
-#define DSCA_PICTURE_PARAMETER_SET_7   0x6B21C
-#define DSCC_PICTURE_PARAMETER_SET_7   0x6BA1C
+#define DSCA_PICTURE_PARAMETER_SET_7   _MMIO(0x6B21C)

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Manasi Navare]

On Fri, Jul 20, 2018 at 09:18:12AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> 
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
> 
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
> 
> This patch helps with backward compatibility for devices pre DP1.3.
> 
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 38 +
>  1 file changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..9d7e1d0b1487 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3738,6 +3738,44 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> + intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_13) {

Like I had mentioned earlier, this check for DP_DPCD_REV is not required infact
if the extended reciever cap field is present its likely that the correct REV 
is present in the different offset
and the original DP_DPCD_REV indicates the legacy or older REV number. This is 
waht i observed when I tested this earlier
on DP 1.4 sink and had to remove this REV check since the original REV register 
was advertising it as DP 1.1 sink.

Manasi

> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
> +  _ext, sizeof(dpcd_ext)) < 0)
> + return false; /* aux transfer failed */
> +
> + if (memcmp(_dp->dpcd[DP_DPCD_REV], _ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DPCD_REV],
> +   dpcd_ext[DP_DPCD_REV]);
> + memcpy(_dp->dpcd[DP_DPCD_REV],
> +_ext[DP_DPCD_REV],
> +sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_MAX_LINK_RATE],
> +   dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
> Present  previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> intel_dp->dpcd);
>  
>   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 09:18:12AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values will match 0h through Fh, except for DPCD_REV,
> MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.
> 
> Read from DPCD once for all 3 values as this is an expensive operation.
> Spec mentions that all of address space 02200h through 0220Fh should
> contain the right information however currently only 3 values can
> differ.
> 
> There is no address space in the intel_dp->dpcd struct for addresses
> 02200h through 0220Fh, and since so much of the data is a identical,
> simply overwrite the values stored in 0h through Fh with the
> values that can be overwritten from addresses 02200h through 0220Fh.
> 
> This patch helps with backward compatibility for devices pre DP1.3.
> 
> v2: read only dpcd values which can be affected, remove incorrect check,
> split into drm include changes into separate patch, commit message,
> verbose debugging statements during overwrite.
> v3: white space fixes
> v4: make path dependent on DPCD revision > 1.2
> 
> Signed-off-by: Matt Atwood 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 38 +
>  1 file changed, 38 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index dde92e4af5d3..9d7e1d0b1487 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3738,6 +3738,44 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
>sizeof(intel_dp->dpcd)) < 0)
>   return false; /* aux transfer failed */
>  
> + if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
> + intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_13) {

wrong order... you don't need to read those bits if ! rev >= 1.3

> + uint8_t dpcd_ext[6];
> +
> + DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
> Present, accessing 02200h through 022FFh\n");
> +
> + if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
> +  _ext, sizeof(dpcd_ext)) < 0)
> + return false; /* aux transfer failed */
> +
> + if (memcmp(_dp->dpcd[DP_DPCD_REV], _ext[DP_DPCD_REV],
> +sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DPCD_REV],
> +   dpcd_ext[DP_DPCD_REV]);
> + memcpy(_dp->dpcd[DP_DPCD_REV],
> +_ext[DP_DPCD_REV],
> +sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
> previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_MAX_LINK_RATE],
> +   dpcd_ext[DP_MAX_LINK_RATE]);
> + memcpy(_dp->dpcd[DP_MAX_LINK_RATE],
> +_ext[DP_MAX_LINK_RATE], sizeof(u8));
> + }
> + if (memcmp(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
> + DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
> Present  previous value %2x new value %2x\n",
> +   intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +   dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
> + memcpy(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
> +_ext[DP_DOWNSTREAMPORT_PRESENT],
> +sizeof(u8));
> + }
> + }
>   DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
> intel_dp->dpcd);
>  
>   return intel_dp->dpcd[DP_DPCD_REV] != 0;
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit

[Rodrigo Vivi]

On Fri, Jul 20, 2018 at 09:18:11AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> This bit was added to DP Training Aux RD interval with DP 1.3. Via
> descriptiion of the spec this field indicates the panels true
> capabilities are described in DPCD address space 02200h through 022FFh.
> 
> v2: version comment update
> v3: version comment correction, commit message update
> 
> Signed-off-by: Matt Atwood 
> ---
>  include/drm/drm_dp_helper.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index c01564991a9f..a03e65042c8e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -123,8 +123,9 @@
>  # define DP_FRAMING_CHANGE_CAP   (1 << 1)
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
> -#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> -# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
> +#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */
> +# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */
   ^ missing a space 
here
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.17.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 unused "ret" variable.

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 05:56:33PM -0700, Nathan Ciobanu wrote:
> On Thu, Jul 19, 2018 at 05:16:03PM -0700, Nathan Ciobanu wrote:
> > On Thu, Jul 19, 2018 at 04:42:17PM -0700, Rodrigo Vivi wrote:
> > > Just a small clean-up with no functional change, only
> > > removing a variable that is never actually used.
> > > 
> > > Cc: Dhinakaran Pandiyan 
> > > Signed-off-by: Rodrigo Vivi 
> > Nice one :)
> > Reviewed-by: 
> Reviewed-by: Nathan Ciobanu 

Thanks, pushed.

> > > ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c | 5 ++---
> > >  1 file changed, 2 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > index 7e3e01607643..18c65f8e4fe8 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > > @@ -263,7 +263,6 @@ static void intel_mst_enable_dp(struct intel_encoder 
> > > *encoder,
> > >   struct intel_dp *intel_dp = _dig_port->dp;
> > >   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > >   enum port port = intel_dig_port->base.port;
> > > - int ret;
> > >  
> > >   DRM_DEBUG_KMS("active links %d\n", intel_dp->active_mst_links);
> > >  
> > > @@ -274,9 +273,9 @@ static void intel_mst_enable_dp(struct intel_encoder 
> > > *encoder,
> > >   1))
> > >   DRM_ERROR("Timed out waiting for ACT sent\n");
> > >  
> > > - ret = drm_dp_check_act_status(_dp->mst_mgr);
> > > + drm_dp_check_act_status(_dp->mst_mgr);
> > >  
> > > - ret = drm_dp_update_payload_part2(_dp->mst_mgr);
> > > + drm_dp_update_payload_part2(_dp->mst_mgr);
> > >   if (pipe_config->has_audio)
> > >   intel_audio_codec_enable(encoder, pipe_config, conn_state);
> > >  }
> > > -- 
> > > 2.17.1
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Show debugfs dpcd read failure directly

[Rodrigo Vivi]

Instead of using a backchannel if some dpcd read failed we
can show that directly on debugfs output.

We are not returning an error because we might still want
to know if sub-sequent reads works, but we shouldn't
need to check 2 places to see why reg is not on the list.

Cc: Jani Nikula 
Cc: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 59dc0610ea44..5d8da4e8c444 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4846,8 +4846,8 @@ static int i915_dpcd_show(struct seq_file *m, void *data)
 
err = drm_dp_dpcd_read(_dp->aux, b->offset, buf, size);
if (err <= 0) {
-   DRM_ERROR("dpcd read (%zu bytes at %u) failed (%zd)\n",
- size, b->offset, err);
+   seq_printf(m, "dpcd read (%zu bytes at %u) failed 
(%zd)\n",
+  size, b->offset, err);
continue;
}
 
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH] drm/i915: Fix psr sink status report.

[Rodrigo Vivi]

On Thu, Jul 19, 2018 at 06:52:00PM -0700, Dhinakaran Pandiyan wrote:
> On Thu, 2018-07-19 at 17:31 -0700, Rodrigo Vivi wrote:
> > First of all don't try to read dpcd if PSR is not even supported.
> > 
> > But also, if read failed return -EIO instead of reporting via a
> > backchannel.
> > 
> > v2: fix dev_priv: At this level m->private is the connector. (CI/DK)
> > don't convert dpcd read errors to EIO. (DK)
> > 
> > Fixes: 5b7b30864d1d ("drm/i915/psr: Split sink status into a separate
> > debugfs node")
> > Cc: Chris Wilson 
> > Cc: Dhinakaran Pandiyan 
> > Cc: José Roberto de Souza 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index b3aefd623557..59dc0610ea44 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2606,13 +2606,22 @@ static int i915_psr_sink_status_show(struct
> > seq_file *m, void *data)
> >     "sink internal error",
> >     };
> >     struct drm_connector *connector = m->private;
> > +   struct drm_i915_private *dev_priv = to_i915(connector->dev);
> >     struct intel_dp *intel_dp =
> >     enc_to_intel_dp(_attached_encoder(connector)-
> > >base);
> > +   int ret;
> > +
> > +   if (!CAN_PSR(dev_priv)) {
> > +   seq_puts(m, "PSR Unsupported\n");
> > +   return -ENODEV;
> > +   }
> >  
> >     if (connector->status != connector_status_connected)
> >     return -ENODEV;
> >  
> > -   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, )
> > == 1) {
> > +   ret = drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS,
> > );
> > +
> > +   if (ret == 1) {
> >     const char *str = "unknown";
> >  
> >     val &= DP_PSR_SINK_STATE_MASK;
> > @@ -2620,7 +2629,7 @@ static int i915_psr_sink_status_show(struct
> > seq_file *m, void *data)
> >     str = sink_status[val];
> >     seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val,
> > str);
> >     } else {
> 
> dpcd_readb() is not expected to return anything other than 1 or a
> negative error code, so this looks good.
> Reviewed-by: Dhinakaran Pandiyan 

thanks, pushed.

> 
> 
> Are you also sending a similar fix for i915_dpcd_show()? That function
> also prints a DRM_ERROR() for failed aux transactions.

well... it is a bit different there because we cannot return in the middle
of the loop because we might want to get other regs read. but probably it
is a good idea to print the error message along with the reads so you don't
have to look to 2 places.

I will put a simple patch and we can wait until Jani is back from
vacation since he was the author there.

> 
> > -   DRM_ERROR("dpcd read (at %u) failed\n",
> > DP_PSR_STATUS);
> > +   return ret;
> >     }
> >  
> >     return 0;
___
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: Fix psr sink status report. (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915: Fix psr sink status report. (rev3)
URL   : https://patchwork.freedesktop.org/series/46831/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4519 -> Patchwork_9735 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL (fdo#107292)


 Possible fixes 

igt@drm_mm@insert_range:
  fi-bsw-n3050:   INCOMPLETE -> PASS

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS
  fi-bxt-j4205:   DMESG-FAIL (fdo#106560) -> PASS

igt@prime_vgem@basic-fence-flip:
  fi-ilk-650: FAIL (fdo#104008) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
  fdo#106560 https://bugs.freedesktop.org/show_bug.cgi?id=106560
  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (44 -> 41) ==

  Additional (2): fi-hsw-4770 fi-byt-n2820 
  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4519 -> Patchwork_9735

  CI_DRM_4519: f14c0ec8fe9acce6fd1be84766f854ab8874eb33 @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9735: 15623bcbe147a8278c1ee24a2109347988434426 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

15623bcbe147 drm/i915: Fix psr sink status report.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 16:13:14)
> 
> On 20/07/2018 11:19, Chris Wilson wrote:
> > +/*
> > + * Once upon a time we supposed that writes through the GGTT would be
> > + * immediately in physical memory (once flushed out of the CPU path). 
> > However,
> > + * on a few different processors and chipsets, this is not necessarily the 
> > case
> > + * as the writes appear to be buffered internally. Thus a read of the 
> > backing
> > + * storage (physical memory) via a different path (with different physical 
> > tags
> > + * to the indirect write via the GGTT) will see stale values from before
> > + * the GGTT write. Inside the kernel, we can for the most part keep track 
> > of
> > + * the different read/write domains in use (e.g. set-domain), but the 
> > assumption
> > + * of coherency is baked into the ABI, hence reporting its true state in 
> > this
> > + * parameter.
> > + *
> > + * If set to true, writes via mmap_gtt are immediately visible following an
> > + * lfence to flush the WCB.
> > + *
> > + * If set to false, writes via mmap_gtt are indeterminatnly delayed in an 
> > in
> > + * internal buffer and are _not_ immediately visible to third parties 
> > accessing
> > + * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
> > + * communications channel when set to false is strongly disadvised.
> 
> I would perhaps change the language from "set to true/false" to 
> "reported as true/false".

s/set/reported/ and pushed. Thanks for the reviews,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/dp: add extended receiver capability field present bit

[matthew . s . atwood]

From: Matt Atwood 

This bit was added to DP Training Aux RD interval with DP 1.3. Via
descriptiion of the spec this field indicates the panels true
capabilities are described in DPCD address space 02200h through 022FFh.

v2: version comment update
v3: version comment correction, commit message update

Signed-off-by: Matt Atwood 
---
 include/drm/drm_dp_helper.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c01564991a9f..a03e65042c8e 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -123,8 +123,9 @@
 # define DP_FRAMING_CHANGE_CAP (1 << 1)
 # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher */
 
-#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
-# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
+#define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
+# define DP_TRAINING_AUX_RD_MASK0x7F/* DP 1.3 */
+# define DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT (1 << 7)/* DP 1.3 */
 
 #define DP_ADAPTER_CAP 0x00f   /* 1.2 */
 # define DP_FORCE_LOAD_SENSE_CAP   (1 << 0)
-- 
2.17.1

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

[Intel-gfx] [PATCH 2/2] drm/i915: implement EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT

[matthew . s . atwood]

From: Matt Atwood 

According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT_PRESENT.

Read from DPCD once for all 3 values as this is an expensive operation.
Spec mentions that all of address space 02200h through 0220Fh should
contain the right information however currently only 3 values can
differ.

There is no address space in the intel_dp->dpcd struct for addresses
02200h through 0220Fh, and since so much of the data is a identical,
simply overwrite the values stored in 0h through Fh with the
values that can be overwritten from addresses 02200h through 0220Fh.

This patch helps with backward compatibility for devices pre DP1.3.

v2: read only dpcd values which can be affected, remove incorrect check,
split into drm include changes into separate patch, commit message,
verbose debugging statements during overwrite.
v3: white space fixes
v4: make path dependent on DPCD revision > 1.2

Signed-off-by: Matt Atwood 
---
 drivers/gpu/drm/i915/intel_dp.c | 38 +
 1 file changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dde92e4af5d3..9d7e1d0b1487 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3738,6 +3738,44 @@ intel_dp_read_dpcd(struct intel_dp *intel_dp)
 sizeof(intel_dp->dpcd)) < 0)
return false; /* aux transfer failed */
 
+   if (intel_dp->dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
+   DP_EXTENDED_RECEIVER_CAP_FIELD_PRESENT &&
+   intel_dp->dpcd[DP_DPCD_REV] >= DP_DPCD_REV_13) {
+   uint8_t dpcd_ext[6];
+
+   DRM_DEBUG_KMS("DPCD: Extended Receiver Capability Field 
Present, accessing 02200h through 022FFh\n");
+
+   if (drm_dp_dpcd_read(_dp->aux, DP_DP13_DPCD_REV,
+_ext, sizeof(dpcd_ext)) < 0)
+   return false; /* aux transfer failed */
+
+   if (memcmp(_dp->dpcd[DP_DPCD_REV], _ext[DP_DPCD_REV],
+  sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Revision 
previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_DPCD_REV],
+ dpcd_ext[DP_DPCD_REV]);
+   memcpy(_dp->dpcd[DP_DPCD_REV],
+  _ext[DP_DPCD_REV],
+  sizeof(u8));
+   }
+   if (memcmp(_dp->dpcd[DP_MAX_LINK_RATE],
+  _ext[DP_MAX_LINK_RATE], sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Max Link Rate 
previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_MAX_LINK_RATE],
+ dpcd_ext[DP_MAX_LINK_RATE]);
+   memcpy(_dp->dpcd[DP_MAX_LINK_RATE],
+  _ext[DP_MAX_LINK_RATE], sizeof(u8));
+   }
+   if (memcmp(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+  _ext[DP_DOWNSTREAMPORT_PRESENT], sizeof(u8))) {
+   DRM_DEBUG_KMS("DPCD: new value for DPCD Downstream Port 
Present  previous value %2x new value %2x\n",
+ intel_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+ dpcd_ext[DP_DOWNSTREAMPORT_PRESENT]);
+   memcpy(_dp->dpcd[DP_DOWNSTREAMPORT_PRESENT],
+  _ext[DP_DOWNSTREAMPORT_PRESENT],
+  sizeof(u8));
+   }
+   }
DRM_DEBUG_KMS("DPCD: %*ph\n", (int) sizeof(intel_dp->dpcd), 
intel_dp->dpcd);
 
return intel_dp->dpcd[DP_DPCD_REV] != 0;
-- 
2.17.1

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

[Intel-gfx] Something is breaking the driver for me

[Jamesie Pic]

Hello everybody !

Sorry but I'm really a noob and I got nowhere to turn to.

I have a lenevo thinkpad x270 on an ultra-dock with 3 external monitors:

00:02.0 VGA compatible controller: Intel Corporation HD Graphics 620 (rev
02)

Since last week's updates in Arch linux, I'm having issues with the screen
in the middle :

- tearing,
- full blue or red pixels appear all over the screen,
- sometimes blanks a few seconds

This makes it really hard for me to work. I have added i915.enable_psr=0,
despite the fact that I never needed this, and it's a least partly usable,
I just have to hang patiently until a bug finishes occurring.

Any suggestion welcome,

Best regards

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

[Intel-gfx] Can recent i915 support more than 8192x8192 screen?

[Marcin Owsiany]

Hello,

*TL;DR*: how can I set a 8960x2880 screen (not display) size on a T580? A
patch for i915 that I found on the internets does not seem to work.

Full story:

I'm a rather happy user of ThinkPad T580 which comes with a
high-density 3840x2160 LCD, and the following graphics hardware.

00:02.0 VGA compatible controller: Intel Corporation Device 5917 (rev 07)
(prog-if 00 [VGA controller])
Subsystem: Lenovo Device 225a
Flags: bus master, fast devsel, latency 0, IRQ 142
Memory at e700 (64-bit, non-prefetchable) [size=16M]
Memory at c000 (64-bit, prefetchable) [size=256M]
I/O ports at e000 [size=64]
[virtual] Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [40] Vendor Specific Information: Len=0c 
Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [100] Process Address Space ID (PASID)
Capabilities: [200] Address Translation Service (ATS)
Capabilities: [300] Page Request Interface (PRI)
Kernel driver in use: i915
Kernel modules: i915

Unfortunately attaching it to an external normal-density 2560x1440 display
means I need to apply scaling. Combined with the side-by-side arrangement
of monitors, this means I'd need to set screen size to 8960x2880. However
this does not work:

 $ xrandr --fb 8960x2880
 xrandr: screen cannot be larger than 8192x8192 (desired size 8960x2880)


I found this thread on reddit

about the same problem, where a user posted a simple patch claimed to be
supplied by someone on #intel-gfx. Unfortunately it does not work (or at
least is not sufficient) - after applying it xrandr does claim
that 16384x16384 is possible, but actually trying to use more
than 8192x8192 fails with an error (unfortunately I lost the exact message).

My current workaround is to pretend that the displays are arranged
vertically, but even after a few months I'm sometimes having trouble
remembering that I need to move mouse cursor UP when I want to go to LEFT
display :-)

I wonder if someone could help me here. Even just getting a definite answer
on whether my hardware can in theory support this or not would be helpful,
since I found conflicting information.

FWIW I'm on Debian stable, Linux 4.9.8x.

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

Re: [Intel-gfx] [PATCHv3] lib/ratelimit: Lockless ratelimiting

[Petr Mladek]

On Wed 2018-07-18 19:49:10, Andy Shevchenko wrote:
> On Tue, Jul 17, 2018 at 3:59 AM, Dmitry Safonov  wrote:
> > I would be glad if someone helps/bothers to review the change :C
> >
> 
> Perhaps Petr and / or Steven can help you.


> > Thanks,
> > Dmitry
> >
> > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
> >> Currently ratelimit_state is protected with spin_lock. If the .lock
> >> is
> >> taken at the moment of ___ratelimit() call, the message is suppressed
> >> to
> >> make ratelimiting robust.
> >>
> >> That results in the following issue issue:
> >>   CPU0  CPU1
> >> --   --
> >> printk_ratelimit()   printk_ratelimit()
> >> | |
> >>   try_spin_lock()  try_spin_lock()
> >> | |
> >> time_is_before_jiffies()  return 0; // suppress
> >>
> >> So, concurrent call of ___ratelimit() results in silently suppressing
> >> one of the messages, regardless if the limit is reached or not.
> >> And rc->missed is not increased in such case so the issue is covered
> >> from user.
> >>
> >> Convert ratelimiting to use atomic counters and drop spin_lock.
> >>
> >> Note: That might be unexpected, but with the first interval of
> >> messages
> >> storm one can print up to burst*2 messages. So, it doesn't guarantee
> >> that in *any* interval amount of messages is lesser than burst.
> >> But, that differs lightly from previous behavior where one can start
> >> burst=5 interval and print 4 messages on the last milliseconds of
> >> interval + new 5 messages from new interval (totally 9 messages in
> >> lesser than interval value):
> >>
> >>msg0  msg1-msg4 msg0-msg4
> >> | |   |
> >> | |   |
> >>  |--o-o-|-o|--> (t)
> >>   <--->
> >>Lesser than burst
> >>

I am a bit confused. Does this patch fix two problems?

   + Lost rc->missed update when try_spin_lock() fails
   + printing up to burst*2 messages in a give interval

It would make the review much easier if you split it into more
patches and fix the problems separately.

Otherwise, it looks promissing...

Best Regards,
Petr

PS: I have vacation the following two weeks. Anyway, please, CC me
if you send any new version.

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

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] igt/gem_mmap_gtt: Check for known incoherency before testing

[Tvrtko Ursulin]

On 20/07/2018 09:07, Chris Wilson wrote:

We test map_gtt coherency (whether or not a write via the mmap_gtt is
immediately visible in the backing storage to a read via mmap_cpu) but
we know that several platforms are inherently incorrect and require some
form of hammer to workaround internal delays. These platforms break our
ABI guarantees and so we report the change in ABI via a driver getparam.

If we know the platform doesn't meet the ABI guarantee, skip the test.
If it is meant to work, test!

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
  tests/gem_mmap_gtt.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mmap_gtt.c
index c8a0bedec..f63535556 100644
--- a/tests/gem_mmap_gtt.c
+++ b/tests/gem_mmap_gtt.c
@@ -309,6 +309,18 @@ test_write_gtt(int fd)
munmap(src, OBJECT_SIZE);
  }
  
+static bool is_coherent(int i915)

+{
+   int val = 1; /* by default, we assume GTT is coherent, hence the test */
+   struct drm_i915_getparam gp = {
+   gp.param = 52, /* GTT_COHERENT */
+   gp.value = ,
+   };
+
+   ioctl(i915, DRM_IOCTL_I915_GETPARAM, );
+   return val;
+}
+
  static void
  test_coherency(int fd)
  {
@@ -316,6 +328,7 @@ test_coherency(int fd)
uint32_t *gtt, *cpu;
int i;
  
+	igt_require(is_coherent(fd));

igt_require(igt_setup_clflush());
  
  	handle = gem_create(fd, OBJECT_SIZE);




Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCHv3] lib/ratelimit: Lockless ratelimiting

[Dmitry Safonov]

On Fri, 2018-07-20 at 17:09 +0200, Petr Mladek wrote:
> > > On Tue, 2018-07-03 at 23:56 +0100, Dmitry Safonov wrote:
> > > > Currently ratelimit_state is protected with spin_lock. If the
> > > > .lock
> > > > is
> > > > taken at the moment of ___ratelimit() call, the message is
> > > > suppressed
> > > > to
> > > > make ratelimiting robust.
> > > > 
> > > > That results in the following issue issue:
> > > >   CPU0  CPU1
> > > > --   --
> > > > printk_ratelimit()   printk_ratelimit()
> > > > | |
> > > >   try_spin_lock()  try_spin_lock()
> > > > | |
> > > > time_is_before_jiffies()  return 0; // suppress
> > > > 
> > > > So, concurrent call of ___ratelimit() results in silently
> > > > suppressing
> > > > one of the messages, regardless if the limit is reached or not.
> > > > And rc->missed is not increased in such case so the issue is
> > > > covered
> > > > from user.
> > > > 
> > > > Convert ratelimiting to use atomic counters and drop spin_lock.
> > > > 
> > > > Note: That might be unexpected, but with the first interval of
> > > > messages
> > > > storm one can print up to burst*2 messages. So, it doesn't
> > > > guarantee
> > > > that in *any* interval amount of messages is lesser than burst.
> > > > But, that differs lightly from previous behavior where one can
> > > > start
> > > > burst=5 interval and print 4 messages on the last milliseconds
> > > > of
> > > > interval + new 5 messages from new interval (totally 9 messages
> > > > in
> > > > lesser than interval value):
> > > > 
> > > >msg0  msg1-msg4 msg0-msg4
> > > > | |   |
> > > > | |   |
> > > >  |--o-o-|-o|--> (t)
> > > >   <--->
> > > >Lesser than burst
> > > > 
> 
> I am a bit confused. Does this patch fix two problems?
> 
>+ Lost rc->missed update when try_spin_lock() fails
>+ printing up to burst*2 messages in a give interval

What I tried to solve here (maybe I could better point it in the commit
message): is the situation where ratelimit::burst haven't been hit yet
and there are calls for __ratelimit() from different CPUs.
So, neither of the messages should be suppressed, but as the spinlock
is taken already - one of them is dropped and even without updating
missed counter.

> It would make the review much easier if you split it into more
> patches and fix the problems separately.

Hmm, not really sure: the patch changes spinlock to atomics and I'm not
sure it make much sense to add atomics before removing the spinlock..

> Otherwise, it looks promissing...
> 
> Best Regards,
> Petr
> 
> PS: I have vacation the following two weeks. Anyway, please, CC me
> if you send any new version.

Surely, thanks for your attention to the patch (and time).

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

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 16:27:20)
> 
> On 20/07/2018 16:21, Chris Wilson wrote:
> > My only plan is for igt to know when the tests are expected to fail.
> > Real userspace should not be using GTT, it is slow (even slower than
> > intended ;) and constrained, so subject to aperture thrashing, fencing
> > is only usable for two out of the many tiling modes, etc, etc, etc.
> 
> I'll take the view that get_param is tiny enough for this to be fine.
> 
> Reviewed-by: Tvrtko Ursulin 

Also take a peek over at
https://patchwork.freedesktop.org/patch/239949/
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Tvrtko Ursulin]

On 20/07/2018 16:21, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-20 16:13:14)


On 20/07/2018 11:19, Chris Wilson wrote:

Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the delay and the resulting coherency
issue.

Similarly, the same inconsistent coherency fouls up our ABI promise that
a write into a mmap_gtt is immediately visible to others. Since the HW
has made that a lie, let userspace know when that contract is broken.
(Not that userspace would want to use mmap_gtt on those chipsets for
other performance reasons...)

Testcase: igt/drv_selftest/live_coherency
Testcase: igt/gem_mmap_gtt/coherency


The list of platforms to mark with false was compiled from the test results?


Yes. Coverage of older chipsets is less than ideal, as we have fewer of
them being tested and the gmch wasn't tied to any processor. So whereas
my PIIIm + i915gm passes, CI's P4 + i915g fails. That is odd.


Hope the oddity is not hiding something but we'll see.


But then before this patch workaround was applied everywhere - so if the
test was failing even then - that means workaround wasn't sufficient?


The test is being run in userspace; bypassing any domain control in the
kernel, assuming the coherency model built into the ABI.


Ah yes.


+/*
+ * Once upon a time we supposed that writes through the GGTT would be
+ * immediately in physical memory (once flushed out of the CPU path). However,
+ * on a few different processors and chipsets, this is not necessarily the case
+ * as the writes appear to be buffered internally. Thus a read of the backing
+ * storage (physical memory) via a different path (with different physical tags
+ * to the indirect write via the GGTT) will see stale values from before
+ * the GGTT write. Inside the kernel, we can for the most part keep track of
+ * the different read/write domains in use (e.g. set-domain), but the 
assumption
+ * of coherency is baked into the ABI, hence reporting its true state in this
+ * parameter.
+ *
+ * If set to true, writes via mmap_gtt are immediately visible following an
+ * lfence to flush the WCB.
+ *
+ * If set to false, writes via mmap_gtt are indeterminatnly delayed in an in
+ * internal buffer and are _not_ immediately visible to third parties accessing
+ * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
+ * communications channel when set to false is strongly disadvised.


I would perhaps change the language from "set to true/false" to
"reported as true/false".


+ */
+#define I915_PARAM_MMAP_GTT_COHERENT 52
+
   typedef struct drm_i915_getparam {
   __s32 param;
   /*



Looks fine to me in principle. Is there some userspace ready to start
consuming it?


My only plan is for igt to know when the tests are expected to fail.
Real userspace should not be using GTT, it is slow (even slower than
intended ;) and constrained, so subject to aperture thrashing, fencing
is only usable for two out of the many tiling modes, etc, etc, etc.


I'll take the view that get_param is tiny enough for this to be fine.

Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 16:13:14)
> 
> On 20/07/2018 11:19, Chris Wilson wrote:
> > Not all chipsets have an internal buffer delaying the visibility of
> > writes via the GGTT being visible by other physical paths, but we use a
> > very heavy workaround for all. We only need to apply that workarounds to
> > the chipsets we know suffer from the delay and the resulting coherency
> > issue.
> > 
> > Similarly, the same inconsistent coherency fouls up our ABI promise that
> > a write into a mmap_gtt is immediately visible to others. Since the HW
> > has made that a lie, let userspace know when that contract is broken.
> > (Not that userspace would want to use mmap_gtt on those chipsets for
> > other performance reasons...)
> > 
> > Testcase: igt/drv_selftest/live_coherency
> > Testcase: igt/gem_mmap_gtt/coherency
> 
> The list of platforms to mark with false was compiled from the test results?

Yes. Coverage of older chipsets is less than ideal, as we have fewer of
them being tested and the gmch wasn't tied to any processor. So whereas
my PIIIm + i915gm passes, CI's P4 + i915g fails. That is odd.
 
> But then before this patch workaround was applied everywhere - so if the 
> test was failing even then - that means workaround wasn't sufficient?

The test is being run in userspace; bypassing any domain control in the
kernel, assuming the coherency model built into the ABI.

> > +/*
> > + * Once upon a time we supposed that writes through the GGTT would be
> > + * immediately in physical memory (once flushed out of the CPU path). 
> > However,
> > + * on a few different processors and chipsets, this is not necessarily the 
> > case
> > + * as the writes appear to be buffered internally. Thus a read of the 
> > backing
> > + * storage (physical memory) via a different path (with different physical 
> > tags
> > + * to the indirect write via the GGTT) will see stale values from before
> > + * the GGTT write. Inside the kernel, we can for the most part keep track 
> > of
> > + * the different read/write domains in use (e.g. set-domain), but the 
> > assumption
> > + * of coherency is baked into the ABI, hence reporting its true state in 
> > this
> > + * parameter.
> > + *
> > + * If set to true, writes via mmap_gtt are immediately visible following an
> > + * lfence to flush the WCB.
> > + *
> > + * If set to false, writes via mmap_gtt are indeterminatnly delayed in an 
> > in
> > + * internal buffer and are _not_ immediately visible to third parties 
> > accessing
> > + * directly via mmap_cpu/mmap_wc. Use of mmap_gtt as part of an IPC
> > + * communications channel when set to false is strongly disadvised.
> 
> I would perhaps change the language from "set to true/false" to 
> "reported as true/false".
> 
> > + */
> > +#define I915_PARAM_MMAP_GTT_COHERENT 52
> > +
> >   typedef struct drm_i915_getparam {
> >   __s32 param;
> >   /*
> > 
> 
> Looks fine to me in principle. Is there some userspace ready to start 
> consuming it?

My only plan is for igt to know when the tests are expected to fail.
Real userspace should not be using GTT, it is slow (even slower than
intended ;) and constrained, so subject to aperture thrashing, fencing
is only usable for two out of the many tiling modes, etc, etc, etc.
-Chris
___
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: Clean up power well descriptors

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up power well descriptors
URL   : https://patchwork.freedesktop.org/series/46952/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9734 =

== Summary - SUCCESS ==

  No regressions found.

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

== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_hangcheck:
  fi-skl-6260u:   PASS -> DMESG-FAIL (fdo#107174, fdo#106560)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
  fi-snb-2520m:   PASS -> INCOMPLETE (fdo#103713)

igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
  fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS


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


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4518 -> Patchwork_9734

  CI_DRM_4518: 85bdcb875339b30f7beecbc7cba6bc2041cdd28b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9734: 0da627a1550ffb580b98834c960cdc91808d58c5 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

0da627a1550f drm/i915/icl: Add missing power gate enums
01e5d715c988 drm/i915: Use existing power well IDs where possible
fd4125220ab9 drm/i915: Make power well ID names more uniform
13de85c0b4d4 drm/i915: Remove redundant power well IDs
ac38cdf6811d drm/i915/ddi: Use power well CTL IDX instead of ID
c543fa2a1967 drm/i915/vlv: Use power well CTL IDX instead of ID
796c168ad9bd drm/i915: Constify power well descriptors
2c558a680c71 drm/i915/vlv: Remove redundant power well ID asserts
bf50420415cd drm/i915: Rename intel_power_domains_fini() to 
intel_power_domains_fini_hw()
b6af654513ed drm/i915/icl: Fix power well anonymous union initializers

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Tvrtko Ursulin]

On 20/07/2018 11:19, Chris Wilson wrote:

Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the delay and the resulting coherency
issue.

Similarly, the same inconsistent coherency fouls up our ABI promise that
a write into a mmap_gtt is immediately visible to others. Since the HW
has made that a lie, let userspace know when that contract is broken.
(Not that userspace would want to use mmap_gtt on those chipsets for
other performance reasons...)

Testcase: igt/drv_selftest/live_coherency
Testcase: igt/gem_mmap_gtt/coherency


The list of platforms to mark with false was compiled from the test results?

But then before this patch workaround was applied everywhere - so if the 
test was failing even then - that means workaround wasn't sufficient?



Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100587
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
---
Resend with --function-context
-Chris
---
  drivers/gpu/drm/i915/i915_drv.c  |  3 +++
  drivers/gpu/drm/i915/i915_gem.c  |  5 +
  drivers/gpu/drm/i915/i915_pci.c  | 10 ++
  drivers/gpu/drm/i915/intel_device_info.h |  1 +
  include/uapi/drm/i915_drm.h  | 22 ++
  5 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f8cfd16be534..18a45e7a3d7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,152 +302,155 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
  static int i915_getparam_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
  {
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
drm_i915_getparam_t *param = data;
int value;
  
  	switch (param->param) {

case I915_PARAM_IRQ_ACTIVE:
case I915_PARAM_ALLOW_BATCHBUFFER:
case I915_PARAM_LAST_DISPATCH:
case I915_PARAM_HAS_EXEC_CONSTANTS:
/* Reject all old ums/dri params. */
return -ENODEV;
case I915_PARAM_CHIPSET_ID:
value = pdev->device;
break;
case I915_PARAM_REVISION:
value = pdev->revision;
break;
case I915_PARAM_NUM_FENCES_AVAIL:
value = dev_priv->num_fence_regs;
break;
case I915_PARAM_HAS_OVERLAY:
value = dev_priv->overlay ? 1 : 0;
break;
case I915_PARAM_HAS_BSD:
value = !!dev_priv->engine[VCS];
break;
case I915_PARAM_HAS_BLT:
value = !!dev_priv->engine[BCS];
break;
case I915_PARAM_HAS_VEBOX:
value = !!dev_priv->engine[VECS];
break;
case I915_PARAM_HAS_BSD2:
value = !!dev_priv->engine[VCS2];
break;
case I915_PARAM_HAS_LLC:
value = HAS_LLC(dev_priv);
break;
case I915_PARAM_HAS_WT:
value = HAS_WT(dev_priv);
break;
case I915_PARAM_HAS_ALIASING_PPGTT:
value = USES_PPGTT(dev_priv);
break;
case I915_PARAM_HAS_SEMAPHORES:
value = HAS_LEGACY_SEMAPHORES(dev_priv);
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
break;
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version(dev_priv);
break;
case I915_PARAM_SUBSLICE_TOTAL:
value = sseu_subslice_total(_INFO(dev_priv)->sseu);
if (!value)
return -ENODEV;
break;
case I915_PARAM_EU_TOTAL:
value = INTEL_INFO(dev_priv)->sseu.eu_total;
if (!value)
return -ENODEV;
break;
case I915_PARAM_HAS_GPU_RESET:
value = i915_modparams.enable_hangcheck &&
intel_has_gpu_reset(dev_priv);
if (value && intel_has_reset_engine(dev_priv))
value = 2;
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
value = HAS_RESOURCE_STREAMER(dev_priv);
break;
case I915_PARAM_HAS_POOLED_EU:
value = HAS_POOLED_EU(dev_priv);
break;
case I915_PARAM_MIN_EU_IN_POOL:
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
value = intel_huc_check_status(_priv->huc);
if (value < 0)

Re: [Intel-gfx] [PATCH v4 1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

[Michał Winiarski]

On Fri, Jul 20, 2018 at 03:33:51PM +0200, Jakub Bartmiński wrote:
> It would appear that the calculated GuC pin bias was larger than it
> should be, as the GuC address space does NOT contain the "HW contexts RSVD"
> part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size.
> 
> Signed-off-by: Jakub Bartmiński 
> Cc: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Michal Wajdeczko 

Cc: Jackie Li 

Matches what I was able to read on GuC view of GGTT.

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/intel_guc.c | 50 ++--
>  1 file changed, 22 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_guc.c 
> b/drivers/gpu/drm/i915/intel_guc.c
> index e12bd259df17..17753952933e 100644
> --- a/drivers/gpu/drm/i915/intel_guc.c
> +++ b/drivers/gpu/drm/i915/intel_guc.c
> @@ -582,50 +582,44 @@ int intel_guc_resume(struct intel_guc *guc)
>   *
>   * ::
>   *
> - * +==> ++ <== GUC_GGTT_TOP
> - * ^||
> - * |||
> - * ||DRAM|
> - * ||   Memory   |
> - * |||
> - *GuC   ||
> - *  Address  +> ++ <== WOPCM Top
> - *   Space   ^  |   HW contexts RSVD |
> - * | |  |WOPCM   |
> - * | | +==> ++ <== GuC WOPCM Top
> - * |GuC^||
> - * |GGTT   |||
> - * |Pin   GuC   |GuC |
> - * |Bias WOPCM  |   WOPCM|
> - * | |Size  ||
> - * | | |||
> - * v v v||
> - * +=+=+==> ++ <== GuC WOPCM Base
> - *  |   Non-GuC WOPCM|
> - *  |   (HuC/Reserved)   |
> - *  ++ <== WOPCM Base
> + * +> ++ <== GUC_GGTT_TOP
> + * ^  ||
> + * |  ||
> + * |  |DRAM|
> + * |  |   Memory   |
> + * |  ||
> + *GuC ||
> + *  Address+> ++ <== GuC WOPCM Top
> + *   Space ^  ||
> + * |   |  ||
> + * |  GuC |GuC |
> + * | WOPCM|   WOPCM|
> + * |  Size||
> + * |   |  ||
> + * v   v  ||
> + * +===+> ++ <== GuC WOPCM Base
>   *
>   * The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped to WOPCM
>   * while upper part of GuC Address Space [ggtt_pin_bias, GUC_GGTT_TOP) is 
> mapped
> - * to DRAM. The value of the GuC ggtt_pin_bias is determined by WOPCM size 
> and
> - * actual GuC WOPCM size.
> + * to DRAM. The value of the GuC ggtt_pin_bias is the GuC WOPCM size.
>   */
>  
>  /**
>   * guc_init_ggtt_pin_bias() - Initialize the GuC ggtt_pin_bias value.
>   * @guc: intel_guc structure.
>   *
> - * This function will calculate and initialize the ggtt_pin_bias value based 
> on
> - * overall WOPCM size and GuC WOPCM size.
> + * This function will calculate and initialize the ggtt_pin_bias value
> + * based on the GuC WOPCM size.
>   */
>  static void guc_init_ggtt_pin_bias(struct intel_guc *guc)
>  {
>   struct drm_i915_private *i915 = guc_to_i915(guc);
>  
>   GEM_BUG_ON(!i915->wopcm.size);
> - GEM_BUG_ON(i915->wopcm.size < i915->wopcm.guc.base);
> + GEM_BUG_ON(range_overflows(i915->wopcm.guc.base, i915->wopcm.guc.size,
> +i915->wopcm.size));
>  
> - guc->ggtt_pin_bias = i915->wopcm.size - i915->wopcm.guc.base;
> + guc->ggtt_pin_bias = i915->wopcm.guc.size;
>  }
>  
>  /**
> -- 
> 2.17.1
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 15:58:51)
> True, it only catches the imbalance in one direction quickly. If suspend 
> idea works go with that, but what's so bad about some log messages? 
> Assuming leak towards the overflow direction on each flip it could be 
> reached in ~18 hours which is realistic to get bug reports of.

A log message means handling bugs reports for years after you fix the bug :)

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

Re: [Intel-gfx] [PATCH] drm/i915: Suppress assertion for i915_ggtt_disable_guc

[Chris Wilson]

Quoting Michał Winiarski (2018-07-20 15:57:49)
> On Fri, Jul 20, 2018 at 10:51:44AM +0100, Chris Wilson wrote:
> > Another step in the drv_module_reload fault-injection saga, is that we
> > try to disable the guc twice. Probably. It's a little unclear exactly
> > what is going on in the unload sequence that catches us out, so for the
> > time being suppress the assertion to get the test re-enabled.
> > 
> > Testcase: igt/drv_module_reload/basic-reload-inject
> > Signed-off-by: Chris Wilson 
> > Cc: Michał Winiarski 
> > Cc: Michal Wajdeczko 
> 
> Reviewed-by: Michał Winiarski 

Out of respect, I'll say this was actually an Acked-by. :)
Hacks like this don't deserve r-b.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Tvrtko Ursulin]

On 20/07/2018 14:59, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-20 14:29:52)


On 20/07/2018 14:02, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-20 13:49:09)


On 12/07/2018 18:38, Chris Wilson wrote:

+ if (rps->interactive)
+ new_power = HIGH_POWER;
+ rps_set_power(dev_priv, new_power);
+ mutex_unlock(>power_lock);

   >
   >  rps->last_adj = 0;

This block should go up to the beginning of the function since when
rps->interactive all preceding calculations are for nothing. And can
immediately return then.


We have to lock around rps_set_power, so you're not going to avoid
taking the lock here, so I don't think it makes any difference.
Certainly neater than locking everything.


Not to avoid the lock but to avoid all the trouble of calculating
new_power to override it all if rps->interactive is set. Just looks a
bit weird. I suspect read of rps->interactive doesn't even need to be
under the lock so maybe:

if (rps->interactive)
 new_power = HIGH_POWER;
} else {
 switch (...)
}


There is a race there, so you do need to explain why we wouldn't care.
(There is a reasonable argument about it being periodic and we don't care
about the first vs interactive.) I thought it came out quite neat as the
atomic override.


Putting it all under the lock works for me then. But okay, if you so 
like the override idea, which I wouldn't call neat, but unusual, it's 
not the end of the world.



+{
+ struct intel_rps *rps = _priv->gt_pm.rps;
+
+ if (INTEL_GEN(dev_priv) < 6)
+ return;
+
+ mutex_lock(>power_lock);
+ if (state) {
+ if (!rps->interactive++ && READ_ONCE(dev_priv->gt.awake))
+ rps_set_power(dev_priv, HIGH_POWER);
+ } else {
+ GEM_BUG_ON(!rps->interactive);
+ rps->interactive--;


Hm maybe protect this in production code so some missed code flows in
the atomic paths do not cause underflow and so permanent interactive mode.


Are you suggesting testing is inadequate? ;) Underflow here isn't a big
deal, it just locks in the HIGH_POWER (faster sampling, bias towards
upclocking). Or worse not allow HIGH_POWER, status quo returned.


Testing for this probably is inadequate, no? Would need to be looking at
the new debugfs flag from many test cases. And in real world probably
quite difficult to debug too.

Whether or not it would be too much to add a DRM_WARN for this.. I am
leaning towards saying to have it, since it is about two systems
communicating together so it would be easier to notice a broken
contract. But I don't insist on it.


Just checking underflow is not going to catch many problems. If we can
identify some points where we know what the value should be... I wonder
if we can assert it is zero at runtime/system suspend.


True, it only catches the imbalance in one direction quickly. If suspend 
idea works go with that, but what's so bad about some log messages? 
Assuming leak towards the overflow direction on each flip it could be 
reached in ~18 hours which is realistic to get bug reports of.


Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Suppress assertion for i915_ggtt_disable_guc

[Michał Winiarski]

On Fri, Jul 20, 2018 at 10:51:44AM +0100, Chris Wilson wrote:
> Another step in the drv_module_reload fault-injection saga, is that we
> try to disable the guc twice. Probably. It's a little unclear exactly
> what is going on in the unload sequence that catches us out, so for the
> time being suppress the assertion to get the test re-enabled.
> 
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Michal Wajdeczko 

Reviewed-by: Michał Winiarski 

-Michał

> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index cff0e6430994..1b476423bfab 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -3654,6 +3654,10 @@ void i915_ggtt_enable_guc(struct drm_i915_private 
> *i915)
>  
>  void i915_ggtt_disable_guc(struct drm_i915_private *i915)
>  {
> + /* XXX Temporary pardon for error unload */
> + if (i915->ggtt.invalidate == gen6_ggtt_invalidate)
> + return;
> +
>   /* We should only be called after i915_ggtt_enable_guc() */
>   GEM_BUG_ON(i915->ggtt.invalidate != guc_ggtt_invalidate);
>  
> -- 
> 2.18.0
> 
___
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: Clean up power well descriptors

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up power well descriptors
URL   : https://patchwork.freedesktop.org/series/46952/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/icl: Fix power well anonymous union initializers
Okay!

Commit: drm/i915: Rename intel_power_domains_fini() to 
intel_power_domains_fini_hw()
Okay!

Commit: drm/i915/vlv: Remove redundant power well ID asserts
Okay!

Commit: drm/i915: Constify power well descriptors
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3645:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3649:16: warning: expression 
using sizeof(void)
+./include/linux/slab.h:631:13: error: undefined identifier 
'__builtin_mul_overflow'
+./include/linux/slab.h:631:13: warning: call with no type!

Commit: drm/i915/vlv: Use power well CTL IDX instead of ID
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3649:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)

Commit: drm/i915/ddi: Use power well CTL IDX instead of ID
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3656:16: warning: expression 
using sizeof(void)
+drivers/gpu/drm/i915/selftests/../i915_drv.h:3669:16: warning: expression 
using sizeof(void)

Commit: drm/i915: Remove redundant power well IDs
Okay!

Commit: drm/i915: Make power well ID names more uniform
Okay!

Commit: drm/i915: Use existing power well IDs where possible
Okay!

Commit: drm/i915/icl: Add missing power gate enums
Okay!

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

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Chris Wilson]

Quoting Lis, Tomasz (2018-07-20 15:41:33)
> 
> 
> On 2018-07-20 12:19, Chris Wilson wrote:
> > Not all chipsets have an internal buffer delaying the visibility of
> > writes via the GGTT being visible by other physical paths, but we use a
> > very heavy workaround for all. We only need to apply that workarounds to
> > the chipsets we know suffer from the delay and the resulting coherency
> > issue.
> >
> > Similarly, the same inconsistent coherency fouls up our ABI promise that
> > a write into a mmap_gtt is immediately visible to others. Since the HW
> > has made that a lie, let userspace know when that contract is broken.
> > (Not that userspace would want to use mmap_gtt on those chipsets for
> > other performance reasons...)
> >
> > Testcase: igt/drv_selftest/live_coherency
> > Testcase: igt/gem_mmap_gtt/coherency
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100587
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> Is there any mention of this bug/feature in bspec? Would be nice to have 
> a reference.

I know that some HW bod has come across it, as they recommended the same
for ordering mem access between us using the GTT for iomaps and GuC
submission. All I know is the background chatter... We don't seem to
have a named w/a; iirc it was just concluded that was the way it was
meant to work ;)
-Chris
___
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: Clean up power well descriptors

[Patchwork]

== Series Details ==

Series: drm/i915: Clean up power well descriptors
URL   : https://patchwork.freedesktop.org/series/46952/
State : warning

== Summary ==

$ dim checkpatch origin/drm-tip
b6af654513ed drm/i915/icl: Fix power well anonymous union initializers
-:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description 
(prefer a maximum 75 chars per line)
#7: 
0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug")

-:7: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ 
chars of sha1> ("")' - ie: 'commit 0a445945be6d ("drm/i915: Work 
around GCC anonymous union initialization bug")'
#7: 
0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug")

total: 1 errors, 1 warnings, 0 checks, 46 lines checked
bf50420415cd drm/i915: Rename intel_power_domains_fini() to 
intel_power_domains_fini_hw()
-:51: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct 
drm_i915_private *' should also have an identifier name
#51: FILE: drivers/gpu/drm/i915/intel_drv.h:1946:
+void intel_power_domains_fini_hw(struct drm_i915_private *);

total: 0 errors, 1 warnings, 0 checks, 106 lines checked
2c558a680c71 drm/i915/vlv: Remove redundant power well ID asserts
796c168ad9bd drm/i915: Constify power well descriptors
-:128: WARNING:FUNCTION_ARGUMENTS: function definition argument 'struct 
drm_i915_private *' should also have an identifier name
#128: FILE: drivers/gpu/drm/i915/intel_drv.h:1945:
+void intel_power_domains_cleanup(struct drm_i915_private *);

-:558: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__power_well_descs' - 
possible side-effects?
#558: FILE: drivers/gpu/drm/i915/intel_runtime_pm.c:2846:
+#define set_power_wells(power_domains, __power_well_descs) \
+   __set_power_wells(power_domains, __power_well_descs, \
+ ARRAY_SIZE(__power_well_descs))

total: 0 errors, 1 warnings, 1 checks, 638 lines checked
c543fa2a1967 drm/i915/vlv: Use power well CTL IDX instead of ID
ac38cdf6811d drm/i915/ddi: Use power well CTL IDX instead of ID
-:264: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in 
parentheses
#264: FILE: drivers/gpu/drm/i915/i915_reg.h:8951:
+#define CNL_AUX_ANAOVRD1(pw_idx)   _MMIO(_PICK(_CNL_AUX_REG_IDX(pw_idx), \
_CNL_AUX_ANAOVRD1_B, \
_CNL_AUX_ANAOVRD1_C, \
_CNL_AUX_ANAOVRD1_D, \

total: 1 errors, 0 warnings, 0 checks, 969 lines checked
13de85c0b4d4 drm/i915: Remove redundant power well IDs
fd4125220ab9 drm/i915: Make power well ID names more uniform
01e5d715c988 drm/i915: Use existing power well IDs where possible
0da627a1550f drm/i915/icl: Add missing power gate enums

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

[Intel-gfx] [PATCH i-g-t] lib/pm: Fix some runtime PM issues

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

1.

It seems that on many systems the hardcoded PCI path in
igt_pm_audio_setup_runtime_pm is not correct.

Add some more paths to work around the issue. More robust solution would
be to look for a symlink of a specific format and use that, such as:

 # ls -ld /sys/bus/pci/drivers/snd_hda_intel/\:00\:1f.3/
 drwxr-xr-x 7 root root 0 Jul 20 14:48 
/sys/bus/pci/drivers/snd_hda_intel/:00:1f.3/

But that's more work, so leave it for a rainy day.

2.

Cleanup handlers were not signal safe - rewrite them.

3.

Along the way I can also export the explicit cleanup function to be called
from individual test cases where that is wanted.

4.

Call the cleanup explicitly from perf_pmu/rc6-runtime-pm.

v2:
 * Skip double restore. (Chris Wilson)
 * Close previously leaked fd.

v3:
 * Refactor atexit handlers to be signal safe. (Chris Wilson)
 * Restore audio runtime PM status.
 * Add a different PCI path to audio device.

v4:
 * Patch renamed and commit message improved.
 * Add another possible PCI bus location.

v5:
 * Wrong PCI device.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v3
---
Dear Santa,

Please don't make this split this up - at least not today since it is
Friday and an unusually warm day! :)
---
 lib/igt_pm.c | 153 ---
 lib/igt_pm.h |   1 +
 tests/perf_pmu.c |   3 +
 3 files changed, 123 insertions(+), 34 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 8ac132269d79..df7b2cd16d66 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,36 +63,74 @@ enum {
 /* Remember to fix this if adding longer strings */
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
+static const char *const __igt_pm_audio_runtime_control_paths[] = {
+   "/sys/bus/pci/devices/:00:03.0/power/control",
+   "/sys/bus/pci/devices/:00:0e.0/power/control",
+   "/sys/bus/pci/devices/:00:1f.3/power/control",
+};
+
 static char __igt_pm_audio_runtime_power_save[64];
+static const char * __igt_pm_audio_runtime_control_path;
 static char __igt_pm_audio_runtime_control[64];
 
-static void __igt_pm_audio_runtime_exit_handler(int sig)
+static int __igt_pm_audio_restore_runtime_pm(void)
 {
int fd;
 
-   igt_debug("Restoring audio power management to '%s' and '%s'\n",
- __igt_pm_audio_runtime_power_save,
- __igt_pm_audio_runtime_control);
+   if (!__igt_pm_audio_runtime_power_save[0])
+   return 0;
 
fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
if (fd < 0)
-   return;
+   return errno;
+
if (write(fd, __igt_pm_audio_runtime_power_save,
  strlen(__igt_pm_audio_runtime_power_save)) !=
-   strlen(__igt_pm_audio_runtime_power_save))
-   igt_warn("Failed to restore audio power_save to '%s'\n",
-__igt_pm_audio_runtime_power_save);
+   strlen(__igt_pm_audio_runtime_power_save)) {
+   close(fd);
+   return errno;
+   }
+
close(fd);
 
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
-   return;
+   return errno;
+
if (write(fd, __igt_pm_audio_runtime_control,
  strlen(__igt_pm_audio_runtime_control)) !=
-   strlen(__igt_pm_audio_runtime_control))
-   igt_warn("Failed to restore audio control to '%s'\n",
-__igt_pm_audio_runtime_control);
+   strlen(__igt_pm_audio_runtime_control)) {
+   close(fd);
+   return errno;
+   }
+
close(fd);
+
+   __igt_pm_audio_runtime_power_save[0] = 0;
+
+   return 0;
+}
+
+static void igt_pm_audio_restore_runtime_pm(void)
+{
+   int ret;
+
+   if (!__igt_pm_audio_runtime_power_save[0])
+   return;
+
+   igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+   ret = __igt_pm_audio_restore_runtime_pm();
+   if (ret)
+   igt_warn("Failed to restore runtime audio PM! (errno=%d)\n",
+ret);
+}
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+   __igt_pm_audio_restore_runtime_pm();
 }
 
 static void strchomp(char *str)
@@ -116,7 +154,7 @@ static void strchomp(char *str)
  */
 void igt_pm_enable_audio_runtime_pm(void)
 {
-   int fd;
+   int fd, i;
 
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
@@ -131,14 +169,23 @@ void igt_pm_enable_audio_runtime_pm(void)
igt_assert_eq(write(fd, "1\n", 2), 2);
close(fd);
}
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
-   if (fd 

Re: [Intel-gfx] [PATCH] drm/i915: Only force GGTT coherency w/a on required chipsets

[Lis, Tomasz]

On 2018-07-20 12:19, Chris Wilson wrote:

Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the delay and the resulting coherency
issue.

Similarly, the same inconsistent coherency fouls up our ABI promise that
a write into a mmap_gtt is immediately visible to others. Since the HW
has made that a lie, let userspace know when that contract is broken.
(Not that userspace would want to use mmap_gtt on those chipsets for
other performance reasons...)

Testcase: igt/drv_selftest/live_coherency
Testcase: igt/gem_mmap_gtt/coherency
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100587
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Is there any mention of this bug/feature in bspec? Would be nice to have 
a reference.


Reviewed-by: Tomasz Lis 

---
Resend with --function-context
-Chris
---
  drivers/gpu/drm/i915/i915_drv.c  |  3 +++
  drivers/gpu/drm/i915/i915_gem.c  |  5 +
  drivers/gpu/drm/i915/i915_pci.c  | 10 ++
  drivers/gpu/drm/i915/intel_device_info.h |  1 +
  include/uapi/drm/i915_drm.h  | 22 ++
  5 files changed, 41 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f8cfd16be534..18a45e7a3d7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -302,152 +302,155 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
  static int i915_getparam_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
  {
struct drm_i915_private *dev_priv = to_i915(dev);
struct pci_dev *pdev = dev_priv->drm.pdev;
drm_i915_getparam_t *param = data;
int value;
  
  	switch (param->param) {

case I915_PARAM_IRQ_ACTIVE:
case I915_PARAM_ALLOW_BATCHBUFFER:
case I915_PARAM_LAST_DISPATCH:
case I915_PARAM_HAS_EXEC_CONSTANTS:
/* Reject all old ums/dri params. */
return -ENODEV;
case I915_PARAM_CHIPSET_ID:
value = pdev->device;
break;
case I915_PARAM_REVISION:
value = pdev->revision;
break;
case I915_PARAM_NUM_FENCES_AVAIL:
value = dev_priv->num_fence_regs;
break;
case I915_PARAM_HAS_OVERLAY:
value = dev_priv->overlay ? 1 : 0;
break;
case I915_PARAM_HAS_BSD:
value = !!dev_priv->engine[VCS];
break;
case I915_PARAM_HAS_BLT:
value = !!dev_priv->engine[BCS];
break;
case I915_PARAM_HAS_VEBOX:
value = !!dev_priv->engine[VECS];
break;
case I915_PARAM_HAS_BSD2:
value = !!dev_priv->engine[VCS2];
break;
case I915_PARAM_HAS_LLC:
value = HAS_LLC(dev_priv);
break;
case I915_PARAM_HAS_WT:
value = HAS_WT(dev_priv);
break;
case I915_PARAM_HAS_ALIASING_PPGTT:
value = USES_PPGTT(dev_priv);
break;
case I915_PARAM_HAS_SEMAPHORES:
value = HAS_LEGACY_SEMAPHORES(dev_priv);
break;
case I915_PARAM_HAS_SECURE_BATCHES:
value = capable(CAP_SYS_ADMIN);
break;
case I915_PARAM_CMD_PARSER_VERSION:
value = i915_cmd_parser_get_version(dev_priv);
break;
case I915_PARAM_SUBSLICE_TOTAL:
value = sseu_subslice_total(_INFO(dev_priv)->sseu);
if (!value)
return -ENODEV;
break;
case I915_PARAM_EU_TOTAL:
value = INTEL_INFO(dev_priv)->sseu.eu_total;
if (!value)
return -ENODEV;
break;
case I915_PARAM_HAS_GPU_RESET:
value = i915_modparams.enable_hangcheck &&
intel_has_gpu_reset(dev_priv);
if (value && intel_has_reset_engine(dev_priv))
value = 2;
break;
case I915_PARAM_HAS_RESOURCE_STREAMER:
value = HAS_RESOURCE_STREAMER(dev_priv);
break;
case I915_PARAM_HAS_POOLED_EU:
value = HAS_POOLED_EU(dev_priv);
break;
case I915_PARAM_MIN_EU_IN_POOL:
value = INTEL_INFO(dev_priv)->sseu.min_eu_in_pool;
break;
case I915_PARAM_HUC_STATUS:
value = intel_huc_check_status(_priv->huc);
if (value < 0)
return value;
break;
case I915_PARAM_MMAP_GTT_VERSION:
/* Though we've 

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Suppress assertion for i915_ggtt_disable_guc

[Patchwork]

== Series Details ==

Series: drm/i915: Suppress assertion for i915_ggtt_disable_guc
URL   : https://patchwork.freedesktop.org/series/46930/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4518_full -> Patchwork_9728_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_9728_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_9728_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

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

  === IGT changes ===

 Warnings 

igt@gem_exec_schedule@deep-blt:
  shard-kbl:  SKIP -> PASS +1

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

igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
  shard-snb:  PASS -> SKIP +1


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@kms_cursor_legacy@pipe-c-torture-bo:
  shard-apl:  PASS -> DMESG-WARN (fdo#107122)

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

igt@kms_flip@2x-plain-flip-ts-check:
  shard-glk:  PASS -> FAIL (fdo#100368)


 Possible fixes 

igt@drv_suspend@shrink:
  shard-kbl:  FAIL (fdo#106886) -> PASS

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

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


  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363
  fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886
  fdo#107122 https://bugs.freedesktop.org/show_bug.cgi?id=107122
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


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

  No changes in participating hosts


== Build changes ==

* Linux: CI_DRM_4518 -> Patchwork_9728

  CI_DRM_4518: 85bdcb875339b30f7beecbc7cba6bc2041cdd28b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9728: 22a6429a57b99e32a73517fe6715563369ab164e @ 
git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ 
git://anongit.freedesktop.org/piglit

== Logs ==

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Ville Syrjälä]

On Fri, Jul 20, 2018 at 03:03:09PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:50:25)
> > On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > > Another question is what happens where there are parallel flips
> > > > happening? One could undo the boost from the other AFAICS. But maybe
> > > > we don't care enough to protect against that?
> > > 
> > > It's a counter, so the "interactive" mode remains high until all
> > > concurrent flips are completed.
> > 
> > Ah. I guess the bool in the atomic state threw me off. I suppose that
> > one is just an optimization to avoid calling the function more than
> > once?
> 
> Yes, it's that I caught the RPS counter going negative. We have more
> cleanup_plane than we prepared I believe that's from
> find_initial_plane.

Hmm. I don't quite see how that could happen. I believe
prepare_fb/cleanup_fb should be fully paired up within a single commit.

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

[Intel-gfx] [PATCH 05/10] drm/i915/vlv: Use power well CTL IDX instead of ID

[Imre Deak]

Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions against the specification more difficult than
necessary. Also the values in the power well ID enum must stay fixed,
making code maintenance of the enum cumbersome.

To solve the above define the control/status flag indices right after
the corresponding registers and use these to derive the control/status
flag values by storing the indices in the i915_power_well_desc struct.

Initializing anonymous unions requires - even named - initializers to
be in order of the struct declaration, hence the reordering of the .id
fields.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.h |  7 +
 drivers/gpu/drm/i915/i915_reg.h | 22 ++
 drivers/gpu/drm/i915/intel_runtime_pm.c | 52 -
 3 files changed, 62 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3ae200a9e8f1..d31a8ef05d18 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -874,6 +874,13 @@ struct i915_power_well_desc {
 */
union {
struct {
+   /*
+* request/status flag index in the PUNIT power well
+* control/status registers.
+*/
+   u8 idx;
+   } vlv;
+   struct {
enum dpio_phy phy;
} bxt;
struct {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8af945d8a995..f76bb4f3c944 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1144,11 +1144,23 @@ enum i915_power_well_id {
 
 #define PUNIT_REG_PWRGT_CTRL   0x60
 #define PUNIT_REG_PWRGT_STATUS 0x61
-#define   PUNIT_PWRGT_MASK(power_well) (3 << ((power_well) * 2))
-#define   PUNIT_PWRGT_PWR_ON(power_well)   (0 << ((power_well) * 2))
-#define   PUNIT_PWRGT_CLK_GATE(power_well) (1 << ((power_well) * 2))
-#define   PUNIT_PWRGT_RESET(power_well)(2 << ((power_well) * 
2))
-#define   PUNIT_PWRGT_PWR_GATE(power_well) (3 << ((power_well) * 2))
+#define   PUNIT_PWRGT_MASK(pw_idx) (3 << ((pw_idx) * 2))
+#define   PUNIT_PWRGT_PWR_ON(pw_idx)   (0 << ((pw_idx) * 2))
+#define   PUNIT_PWRGT_CLK_GATE(pw_idx) (1 << ((pw_idx) * 2))
+#define   PUNIT_PWRGT_RESET(pw_idx)(2 << ((pw_idx) * 2))
+#define   PUNIT_PWRGT_PWR_GATE(pw_idx) (3 << ((pw_idx) * 2))
+
+#define PUNIT_PWGT_IDX_RENDER  0
+#define PUNIT_PWGT_IDX_MEDIA   1
+#define PUNIT_PWGT_IDX_DISP2D  3
+#define PUNIT_PWGT_IDX_DPIO_CMN_BC 5
+#define PUNIT_PWGT_IDX_DPIO_TX_B_LANES_01  6
+#define PUNIT_PWGT_IDX_DPIO_TX_B_LANES_23  7
+#define PUNIT_PWGT_IDX_DPIO_TX_C_LANES_01  8
+#define PUNIT_PWGT_IDX_DPIO_TX_C_LANES_23  9
+#define PUNIT_PWGT_IDX_DPIO_RX010
+#define PUNIT_PWGT_IDX_DPIO_RX111
+#define PUNIT_PWGT_IDX_DPIO_CMN_D  12
 
 #define PUNIT_REG_GPU_LFM  0xd3
 #define PUNIT_REG_GPU_FREQ_REQ 0xd4
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 8b3c241bee55..05d8cdab08cc 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -872,14 +872,14 @@ static void i830_pipes_power_well_sync_hw(struct 
drm_i915_private *dev_priv,
 static void vlv_set_power_well(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well, bool enable)
 {
-   enum i915_power_well_id power_well_id = power_well->desc->id;
+   int pw_idx = power_well->desc->vlv.idx;
u32 mask;
u32 state;
u32 ctrl;
 
-   mask = PUNIT_PWRGT_MASK(power_well_id);
-   state = enable ? PUNIT_PWRGT_PWR_ON(power_well_id) :
-PUNIT_PWRGT_PWR_GATE(power_well_id);
+   mask = PUNIT_PWRGT_MASK(pw_idx);
+   state = enable ? PUNIT_PWRGT_PWR_ON(pw_idx) :
+PUNIT_PWRGT_PWR_GATE(pw_idx);
 
mutex_lock(_priv->pcu_lock);
 
@@ -920,14 +920,14 @@ static void vlv_power_well_disable(struct 
drm_i915_private *dev_priv,
 static bool vlv_power_well_enabled(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   enum i915_power_well_id power_well_id = power_well->desc->id;
+   int pw_idx = power_well->desc->vlv.idx;
bool enabled = false;
u32 mask;
   

[Intel-gfx] [PATCH 02/10] drm/i915: Rename intel_power_domains_fini() to intel_power_domains_fini_hw()

[Imre Deak]

intel_power_domains_fini() rolls back what was done in
intel_power_domains_init_hw(), so rename and move it accordingly. This
allows us adding a cleanup function later for intel_power_domains_init()
in a cleaner way.

No functional change.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c |  4 +-
 drivers/gpu/drm/i915/intel_drv.h|  2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 69 -
 3 files changed, 37 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3834bd758a2e..3c984530fef9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -709,7 +709,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
intel_teardown_gmbus(dev_priv);
 cleanup_csr:
intel_csr_ucode_fini(dev_priv);
-   intel_power_domains_fini(dev_priv);
+   intel_power_domains_fini_hw(dev_priv);
vga_switcheroo_unregister_client(pdev);
 cleanup_vga_client:
vga_client_register(pdev, NULL, NULL, NULL);
@@ -1460,7 +1460,7 @@ void i915_driver_unload(struct drm_device *dev)
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
 
-   intel_power_domains_fini(dev_priv);
+   intel_power_domains_fini_hw(dev_priv);
 
i915_driver_cleanup_hw(dev_priv);
i915_driver_cleanup_mmio(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 5b4414f06aae..32be305c0e89 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1943,8 +1943,8 @@ int intel_psr_wait_for_idle(const struct intel_crtc_state 
*new_crtc_state);
 
 /* intel_runtime_pm.c */
 int intel_power_domains_init(struct drm_i915_private *);
-void intel_power_domains_fini(struct drm_i915_private *);
 void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool 
resume);
+void intel_power_domains_fini_hw(struct drm_i915_private *);
 void intel_power_domains_suspend(struct drm_i915_private *dev_priv);
 void intel_power_domains_verify_state(struct drm_i915_private *dev_priv);
 void bxt_display_core_init(struct drm_i915_private *dev_priv, bool resume);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 1a87176a85c1..f1742466436d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2902,41 +2902,6 @@ int intel_power_domains_init(struct drm_i915_private 
*dev_priv)
return 0;
 }
 
-/**
- * intel_power_domains_fini - finalizes the power domain structures
- * @dev_priv: i915 device instance
- *
- * Finalizes the power domain structures for @dev_priv depending upon the
- * supported platform. This function also disables runtime pm and ensures that
- * the device stays powered up so that the driver can be reloaded.
- */
-void intel_power_domains_fini(struct drm_i915_private *dev_priv)
-{
-   struct device *kdev = _priv->drm.pdev->dev;
-
-   /*
-* The i915.ko module is still not prepared to be loaded when
-* the power well is not enabled, so just enable it in case
-* we're going to unload/reload.
-* The following also reacquires the RPM reference the core passed
-* to the driver during loading, which is dropped in
-* intel_runtime_pm_enable(). We have to hand back the control of the
-* device to the core with this reference held.
-*/
-   intel_display_set_init_power(dev_priv, true);
-
-   /* Remove the refcount we took to keep power well support disabled. */
-   if (!i915_modparams.disable_power_well)
-   intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
-
-   /*
-* Remove the refcount we took in intel_runtime_pm_enable() in case
-* the platform doesn't support runtime PM.
-*/
-   if (!HAS_RUNTIME_PM(dev_priv))
-   pm_runtime_put(kdev);
-}
-
 static void intel_power_domains_sync_hw(struct drm_i915_private *dev_priv)
 {
struct i915_power_domains *power_domains = _priv->power_domains;
@@ -3581,6 +3546,40 @@ void intel_power_domains_init_hw(struct drm_i915_private 
*dev_priv, bool resume)
 }
 
 /**
+ * intel_power_domains_fini_hw - deinitialize hw power domain state
+ * @dev_priv: i915 device instance
+ *
+ * De-initializes the display power domain HW state. It also ensures that the
+ * device stays powered up so that the driver can be reloaded.
+ */
+void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv)
+{
+   struct device *kdev = _priv->drm.pdev->dev;
+
+   /*
+* The i915.ko module is still not prepared to be loaded when
+* the power well is not enabled, so just enable it in case
+* we're going to unload/reload.
+* The following also reacquires the RPM reference the core passed
+* to the driver during loading, which 

[Intel-gfx] [PATCH 00/10] drm/i915: Clean up power well descriptors

[Imre Deak]

Paulo noted that the complexity in the macros for determining the power
well register and request/status HW flag offsets is overly complicated.
This patchset improves on that by removing the dependence on the power
well ID enum when determining these and instead defining the
correpsonding power well indices right after their register definitions.

While at it the patchset also turns unchanging fields in i915_power_well
to const.

Cc: Chris Wilson 
Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 

Imre Deak (10):
  drm/i915/icl: Fix power well anonymous union initializers
  drm/i915: Rename intel_power_domains_fini() to
intel_power_domains_fini_hw()
  drm/i915/vlv: Remove redundant power well ID asserts
  drm/i915: Constify power well descriptors
  drm/i915/vlv: Use power well CTL IDX instead of ID
  drm/i915/ddi: Use power well CTL IDX instead of ID
  drm/i915: Remove redundant power well IDs
  drm/i915: Make power well ID names more uniform
  drm/i915: Use existing power well IDs where possible
  drm/i915/icl: Add missing power gate enums

 drivers/gpu/drm/i915/gvt/handlers.c |  30 +-
 drivers/gpu/drm/i915/i915_debugfs.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c |  12 +-
 drivers/gpu/drm/i915/i915_drv.h |  34 +-
 drivers/gpu/drm/i915/i915_reg.h | 271 +--
 drivers/gpu/drm/i915/intel_display.c|   5 +-
 drivers/gpu/drm/i915/intel_display.h|   4 +-
 drivers/gpu/drm/i915/intel_drv.h|   3 +-
 drivers/gpu/drm/i915/intel_hdcp.c   |   6 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 788 +---
 10 files changed, 697 insertions(+), 460 deletions(-)

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

[Intel-gfx] [PATCH 09/10] drm/i915: Use existing power well IDs where possible

[Imre Deak]

There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum values.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 ---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b6076f712db5..19b4eac1cc8a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1045,9 +1045,6 @@ enum i915_power_well_id {
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_1,
SKL_DISP_PW_2,
-   BXT_DPIO_CMN_BC,
-   ICL_DISP_PW_1,
-   ICL_DISP_PW_2,
 };
 
 #define PUNIT_REG_PWRGT_CTRL   0x60
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 56161d0dc3ca..b7acf54d8a72 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -772,7 +772,7 @@ static void bxt_verify_ddi_phy_power_wells(struct 
drm_i915_private *dev_priv)
if (power_well->count > 0)
bxt_ddi_phy_verify_state(dev_priv, power_well->desc->bxt.phy);
 
-   power_well = lookup_power_well(dev_priv, BXT_DPIO_CMN_BC);
+   power_well = lookup_power_well(dev_priv, VLV_DISP_PW_DPIO_CMN_BC);
if (power_well->count > 0)
bxt_ddi_phy_verify_state(dev_priv, power_well->desc->bxt.phy);
 
@@ -2456,7 +2456,7 @@ static const struct i915_power_well_desc 
bxt_power_wells[] = {
.name = "dpio-common-bc",
.domains = BXT_DPIO_CMN_BC_POWER_DOMAINS,
.ops = _dpio_cmn_power_well_ops,
-   .id = BXT_DPIO_CMN_BC,
+   .id = VLV_DISP_PW_DPIO_CMN_BC,
{
.bxt.phy = DPIO_PHY0,
},
@@ -2515,7 +2515,7 @@ static const struct i915_power_well_desc 
glk_power_wells[] = {
.name = "dpio-common-b",
.domains = GLK_DPIO_CMN_B_POWER_DOMAINS,
.ops = _dpio_cmn_power_well_ops,
-   .id = BXT_DPIO_CMN_BC,
+   .id = VLV_DISP_PW_DPIO_CMN_BC,
{
.bxt.phy = DPIO_PHY0,
},
@@ -2764,7 +2764,7 @@ static const struct i915_power_well_desc 
icl_power_wells[] = {
/* Handled by the DMC firmware */
.domains = 0,
.ops = _power_well_ops,
-   .id = ICL_DISP_PW_1,
+   .id = SKL_DISP_PW_1,
{
.hsw.regs = _power_well_regs,
.hsw.idx = ICL_PW_CTL_IDX_PW_1,
@@ -3584,7 +3584,7 @@ static void icl_display_core_init(struct drm_i915_private 
*dev_priv,
 *The AUX IO power wells will be enabled on demand.
 */
mutex_lock(_domains->lock);
-   well = lookup_power_well(dev_priv, ICL_DISP_PW_1);
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
intel_power_well_enable(dev_priv, well);
mutex_unlock(_domains->lock);
 
@@ -3625,7 +3625,7 @@ static void icl_display_core_uninit(struct 
drm_i915_private *dev_priv)
 *disabled at this point.
 */
mutex_lock(_domains->lock);
-   well = lookup_power_well(dev_priv, ICL_DISP_PW_1);
+   well = lookup_power_well(dev_priv, SKL_DISP_PW_1);
intel_power_well_disable(dev_priv, well);
mutex_unlock(_domains->lock);
 
-- 
2.13.2

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

[Intel-gfx] [PATCH 08/10] drm/i915: Make power well ID names more uniform

[Imre Deak]

The format for the ID names is _DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h | 10 
 drivers/gpu/drm/i915/intel_runtime_pm.c | 44 -
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9b3635009826..b6076f712db5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1036,16 +1036,16 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 enum i915_power_well_id {
DISP_PW_ID_NONE,
 
-   PUNIT_POWER_WELL_DISP2D,
-   PUNIT_POWER_WELL_DPIO_CMN_BC,
-   PUNIT_POWER_WELL_DPIO_CMN_D,
+   VLV_DISP_PW_DISP2D,
+   BXT_DISP_PW_DPIO_CMN_A,
+   VLV_DISP_PW_DPIO_CMN_BC,
+   GLK_DISP_PW_DPIO_CMN_C,
+   CHV_DISP_PW_DPIO_CMN_D,
HSW_DISP_PW_GLOBAL,
SKL_DISP_PW_MISC_IO,
SKL_DISP_PW_1,
SKL_DISP_PW_2,
-   BXT_DPIO_CMN_A,
BXT_DPIO_CMN_BC,
-   GLK_DPIO_CMN_C,
ICL_DISP_PW_1,
ICL_DISP_PW_2,
 };
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 792394d20f62..56161d0dc3ca 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -768,7 +768,7 @@ static void bxt_verify_ddi_phy_power_wells(struct 
drm_i915_private *dev_priv)
 {
struct i915_power_well *power_well;
 
-   power_well = lookup_power_well(dev_priv, BXT_DPIO_CMN_A);
+   power_well = lookup_power_well(dev_priv, BXT_DISP_PW_DPIO_CMN_A);
if (power_well->count > 0)
bxt_ddi_phy_verify_state(dev_priv, power_well->desc->bxt.phy);
 
@@ -777,7 +777,7 @@ static void bxt_verify_ddi_phy_power_wells(struct 
drm_i915_private *dev_priv)
bxt_ddi_phy_verify_state(dev_priv, power_well->desc->bxt.phy);
 
if (IS_GEMINILAKE(dev_priv)) {
-   power_well = lookup_power_well(dev_priv, GLK_DPIO_CMN_C);
+   power_well = lookup_power_well(dev_priv, 
GLK_DISP_PW_DPIO_CMN_C);
if (power_well->count > 0)
bxt_ddi_phy_verify_state(dev_priv,
 power_well->desc->bxt.phy);
@@ -1129,9 +1129,9 @@ lookup_power_well(struct drm_i915_private *dev_priv,
 static void assert_chv_phy_status(struct drm_i915_private *dev_priv)
 {
struct i915_power_well *cmn_bc =
-   lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC);
+   lookup_power_well(dev_priv, VLV_DISP_PW_DPIO_CMN_BC);
struct i915_power_well *cmn_d =
-   lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_D);
+   lookup_power_well(dev_priv, CHV_DISP_PW_DPIO_CMN_D);
u32 phy_control = dev_priv->chv_phy_control;
u32 phy_status = 0;
u32 phy_status_mask = 0x;
@@ -1241,10 +1241,10 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
enum pipe pipe;
uint32_t tmp;
 
-   WARN_ON_ONCE(power_well->desc->id != PUNIT_POWER_WELL_DPIO_CMN_BC &&
-power_well->desc->id != PUNIT_POWER_WELL_DPIO_CMN_D);
+   WARN_ON_ONCE(power_well->desc->id != VLV_DISP_PW_DPIO_CMN_BC &&
+power_well->desc->id != CHV_DISP_PW_DPIO_CMN_D);
 
-   if (power_well->desc->id == PUNIT_POWER_WELL_DPIO_CMN_BC) {
+   if (power_well->desc->id == VLV_DISP_PW_DPIO_CMN_BC) {
pipe = PIPE_A;
phy = DPIO_PHY0;
} else {
@@ -1272,7 +1272,7 @@ static void chv_dpio_cmn_power_well_enable(struct 
drm_i915_private *dev_priv,
DPIO_SUS_CLK_CONFIG_GATE_CLKREQ;
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW28, tmp);
 
-   if (power_well->desc->id == PUNIT_POWER_WELL_DPIO_CMN_BC) {
+   if (power_well->desc->id == VLV_DISP_PW_DPIO_CMN_BC) {
tmp = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW6_CH1);
tmp |= DPIO_DYNPWRDOWNEN_CH1;
vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW6_CH1, tmp);
@@ -1303,10 +1303,10 @@ static void chv_dpio_cmn_power_well_disable(struct 
drm_i915_private *dev_priv,
 {
enum dpio_phy phy;
 
-   WARN_ON_ONCE(power_well->desc->id != PUNIT_POWER_WELL_DPIO_CMN_BC &&
-power_well->desc->id != PUNIT_POWER_WELL_DPIO_CMN_D);
+   WARN_ON_ONCE(power_well->desc->id != VLV_DISP_PW_DPIO_CMN_BC &&
+power_well->desc->id != CHV_DISP_PW_DPIO_CMN_D);
 
-   if (power_well->desc->id == PUNIT_POWER_WELL_DPIO_CMN_BC) {
+   if (power_well->desc->id == VLV_DISP_PW_DPIO_CMN_BC) {
phy = DPIO_PHY0;
assert_pll_disabled(dev_priv, PIPE_A);
assert_pll_disabled(dev_priv, 

[Intel-gfx] [PATCH 06/10] drm/i915/ddi: Use power well CTL IDX instead of ID

[Imre Deak]

Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.

Also clarify a bit the code comment describing the function and layout
of the control registers.

This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/gvt/handlers.c |  30 +---
 drivers/gpu/drm/i915/i915_drv.h |  13 ++
 drivers/gpu/drm/i915/i915_reg.h | 126 -
 drivers/gpu/drm/i915/intel_display.c|   5 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 302 ++--
 5 files changed, 359 insertions(+), 117 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index 7a58ca555197..79e748569d31 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1287,12 +1287,12 @@ static int power_well_ctl_mmio_write(struct intel_vgpu 
*vgpu,
 {
write_vreg(vgpu, offset, p_data, bytes);
 
-   if (vgpu_vreg(vgpu, offset) & HSW_PWR_WELL_CTL_REQ(HSW_DISP_PW_GLOBAL))
+   if (vgpu_vreg(vgpu, offset) & 
HSW_PWR_WELL_CTL_REQ(HSW_PW_CTL_IDX_GLOBAL))
vgpu_vreg(vgpu, offset) |=
-   HSW_PWR_WELL_CTL_STATE(HSW_DISP_PW_GLOBAL);
+   HSW_PWR_WELL_CTL_STATE(HSW_PW_CTL_IDX_GLOBAL);
else
vgpu_vreg(vgpu, offset) &=
-   ~HSW_PWR_WELL_CTL_STATE(HSW_DISP_PW_GLOBAL);
+   ~HSW_PWR_WELL_CTL_STATE(HSW_PW_CTL_IDX_GLOBAL);
return 0;
 }
 
@@ -2443,17 +2443,10 @@ static int init_generic_mmio_info(struct intel_gvt *gvt)
MMIO_D(GEN6_RC6p_THRESHOLD, D_ALL);
MMIO_D(GEN6_RC6pp_THRESHOLD, D_ALL);
MMIO_D(GEN6_PMINTRMSK, D_ALL);
-   /*
-* Use an arbitrary power well controlled by the PWR_WELL_CTL
-* register.
-*/
-   MMIO_DH(HSW_PWR_WELL_CTL_BIOS(HSW_DISP_PW_GLOBAL), D_BDW, NULL,
-   power_well_ctl_mmio_write);
-   MMIO_DH(HSW_PWR_WELL_CTL_DRIVER(HSW_DISP_PW_GLOBAL), D_BDW, NULL,
-   power_well_ctl_mmio_write);
-   MMIO_DH(HSW_PWR_WELL_CTL_KVMR, D_BDW, NULL, power_well_ctl_mmio_write);
-   MMIO_DH(HSW_PWR_WELL_CTL_DEBUG(HSW_DISP_PW_GLOBAL), D_BDW, NULL,
-   power_well_ctl_mmio_write);
+   MMIO_DH(HSW_PWR_WELL_CTL1, D_BDW, NULL, power_well_ctl_mmio_write);
+   MMIO_DH(HSW_PWR_WELL_CTL2, D_BDW, NULL, power_well_ctl_mmio_write);
+   MMIO_DH(HSW_PWR_WELL_CTL3, D_BDW, NULL, power_well_ctl_mmio_write);
+   MMIO_DH(HSW_PWR_WELL_CTL4, D_BDW, NULL, power_well_ctl_mmio_write);
MMIO_DH(HSW_PWR_WELL_CTL5, D_BDW, NULL, power_well_ctl_mmio_write);
MMIO_DH(HSW_PWR_WELL_CTL6, D_BDW, NULL, power_well_ctl_mmio_write);
 
@@ -2804,13 +2797,8 @@ static int init_skl_mmio_info(struct intel_gvt *gvt)
MMIO_F(_MMIO(_DPD_AUX_CH_CTL), 6 * 4, 0, 0, 0, D_SKL_PLUS, NULL,
dp_aux_ch_ctl_mmio_write);
 
-   /*
-* Use an arbitrary power well controlled by the PWR_WELL_CTL
-* register.
-*/
-   MMIO_D(HSW_PWR_WELL_CTL_BIOS(SKL_DISP_PW_MISC_IO), D_SKL_PLUS);
-   MMIO_DH(HSW_PWR_WELL_CTL_DRIVER(SKL_DISP_PW_MISC_IO), D_SKL_PLUS, NULL,
-   skl_power_well_ctl_write);
+   MMIO_D(HSW_PWR_WELL_CTL1, D_SKL_PLUS);
+   MMIO_DH(HSW_PWR_WELL_CTL2, D_SKL_PLUS, NULL, skl_power_well_ctl_write);
 
MMIO_D(_MMIO(0xa210), D_SKL_PLUS);
MMIO_D(GEN9_MEDIA_PG_IDLE_HYSTERESIS, D_SKL_PLUS);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d31a8ef05d18..d73ce0a7b8f7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -861,6 +861,13 @@ struct i915_power_well_ops {
   struct i915_power_well *power_well);
 };
 
+struct i915_power_well_regs {
+   i915_reg_t bios;
+   i915_reg_t driver;
+   i915_reg_t kvmr;
+   i915_reg_t debug;
+};
+
 /* Power well structure for haswell */
 struct i915_power_well_desc {
const char *name;
@@ -884,6 +891,12 @@ struct i915_power_well_desc {
enum dpio_phy phy;
} bxt;
struct {
+   const struct i915_power_well_regs *regs;
+   /*
+* request/status flag index in the power well
+* constrol/status registers.
+*/
+   u8 idx;
/* Mask of pipes whose 

[Intel-gfx] [PATCH 10/10] drm/i915/icl: Add missing power gate enums

[Imre Deak]

On ICL there are 5 fused power gates, so add the two missing ones for
clarity.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19b4eac1cc8a..7b6fba25614e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8830,6 +8830,8 @@ enum skl_power_gate {
SKL_PG0,
SKL_PG1,
SKL_PG2,
+   ICL_PG3,
+   ICL_PG4,
 };
 
 #define SKL_FUSE_STATUS_MMIO(0x42000)
-- 
2.13.2

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

[Intel-gfx] [PATCH 07/10] drm/i915: Remove redundant power well IDs

[Imre Deak]

Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting power wells and hopefully won't be needed for any new
power wells in the future. To make maintenance of the power well ID enum
easier, don't require a unique ID for each power well, only if it's
necessary. Remove the IDs becoming redundant this way and assign to all
the corresponding power wells a new DISP_PW_ID_NONE ID.

After the previous two patches the IDs don't need to have a fixed value,
so remove the explicit initializers and adjust the enum's code comment
accordingly.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_reg.h | 118 -
 drivers/gpu/drm/i915/intel_runtime_pm.c | 129 
 2 files changed, 79 insertions(+), 168 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b7022fb8d524..9b3635009826 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1029,117 +1029,25 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 /*
  * i915_power_well_id:
  *
- * Platform specific IDs used to look up power wells and - except for custom
- * power wells - to define request/status register flag bit positions. As such
- * the set of IDs on a given platform must be unique and except for custom
- * power wells their value must stay fixed.
+ * IDs used to look up power wells. Power wells accessed directly bypassing
+ * the power domains framework must be assigned a unique ID. The rest of power
+ * wells must be assigned DISP_PW_ID_NONE.
  */
 enum i915_power_well_id {
-   /*
-* I830
-*  - custom power well
-*/
-   I830_DISP_PW_PIPES = 0,
-
-   /*
-* VLV/CHV
-*  - PUNIT_REG_PWRGT_CTRL (bit: id*2),
-*PUNIT_REG_PWRGT_STATUS (bit: id*2) (PUNIT HAS v0.8)
-*/
-   PUNIT_POWER_WELL_RENDER = 0,
-   PUNIT_POWER_WELL_MEDIA  = 1,
-   PUNIT_POWER_WELL_DISP2D = 3,
-   PUNIT_POWER_WELL_DPIO_CMN_BC= 5,
-   PUNIT_POWER_WELL_DPIO_TX_B_LANES_01 = 6,
-   PUNIT_POWER_WELL_DPIO_TX_B_LANES_23 = 7,
-   PUNIT_POWER_WELL_DPIO_TX_C_LANES_01 = 8,
-   PUNIT_POWER_WELL_DPIO_TX_C_LANES_23 = 9,
-   PUNIT_POWER_WELL_DPIO_RX0   = 10,
-   PUNIT_POWER_WELL_DPIO_RX1   = 11,
-   PUNIT_POWER_WELL_DPIO_CMN_D = 12,
-   /*  - custom power well */
-   CHV_DISP_PW_PIPE_A, /* 13 */
-
-   /*
-* HSW/BDW
-*  - _HSW_PWR_WELL_CTL1-4 (status bit: id*2, req bit: id*2+1)
-*/
-   HSW_DISP_PW_GLOBAL = 15,
-
-   /*
-* GEN9+
-*  - _HSW_PWR_WELL_CTL1-4 (status bit: id*2, req bit: id*2+1)
-*/
-   SKL_DISP_PW_MISC_IO = 0,
-   SKL_DISP_PW_DDI_A_E,
-   GLK_DISP_PW_DDI_A = SKL_DISP_PW_DDI_A_E,
-   CNL_DISP_PW_DDI_A = SKL_DISP_PW_DDI_A_E,
-   SKL_DISP_PW_DDI_B,
-   SKL_DISP_PW_DDI_C,
-   SKL_DISP_PW_DDI_D,
-   CNL_DISP_PW_DDI_F = 6,
-
-   GLK_DISP_PW_AUX_A = 8,
-   GLK_DISP_PW_AUX_B,
-   GLK_DISP_PW_AUX_C,
-   CNL_DISP_PW_AUX_A = GLK_DISP_PW_AUX_A,
-   CNL_DISP_PW_AUX_B = GLK_DISP_PW_AUX_B,
-   CNL_DISP_PW_AUX_C = GLK_DISP_PW_AUX_C,
-   CNL_DISP_PW_AUX_D,
-   CNL_DISP_PW_AUX_F,
-
-   SKL_DISP_PW_1 = 14,
+   DISP_PW_ID_NONE,
+
+   PUNIT_POWER_WELL_DISP2D,
+   PUNIT_POWER_WELL_DPIO_CMN_BC,
+   PUNIT_POWER_WELL_DPIO_CMN_D,
+   HSW_DISP_PW_GLOBAL,
+   SKL_DISP_PW_MISC_IO,
+   SKL_DISP_PW_1,
SKL_DISP_PW_2,
-
-   /* - custom power wells */
BXT_DPIO_CMN_A,
BXT_DPIO_CMN_BC,
-   GLK_DPIO_CMN_C, /* 18 */
-
-   /*
-* GEN11+
-*  - _HSW_PWR_WELL_CTL1-4
-*(status bit: (id&15)*2, req bit:(id&15)*2+1)
-*/
-   ICL_DISP_PW_1 = 0,
+   GLK_DPIO_CMN_C,
+   ICL_DISP_PW_1,
ICL_DISP_PW_2,
-   ICL_DISP_PW_3,
-   ICL_DISP_PW_4,
-
-   /*
-*  - _HSW_PWR_WELL_CTL_AUX1/2/4
-*(status bit: (id&15)*2, req bit:(id&15)*2+1)
-*/
-   ICL_DISP_PW_AUX_A = 16,
-   ICL_DISP_PW_AUX_B,
-   ICL_DISP_PW_AUX_C,
-   ICL_DISP_PW_AUX_D,
-   ICL_DISP_PW_AUX_E,
-   ICL_DISP_PW_AUX_F,
-
-   ICL_DISP_PW_AUX_TBT1 = 24,
-   ICL_DISP_PW_AUX_TBT2,
-   ICL_DISP_PW_AUX_TBT3,
-   ICL_DISP_PW_AUX_TBT4,
-
-   /*
-*  - _HSW_PWR_WELL_CTL_DDI1/2/4
-*(status bit: (id&15)*2, req bit:(id&15)*2+1)
-*/
-   ICL_DISP_PW_DDI_A = 32,
-   ICL_DISP_PW_DDI_B,
-   ICL_DISP_PW_DDI_C,
-   ICL_DISP_PW_DDI_D,
-   

[Intel-gfx] [PATCH 03/10] drm/i915/vlv: Remove redundant power well ID asserts

[Imre Deak]

The callbacks these asserts are called from are used from a single power
well, so not much point in checking that. The check also requires a unique
power well ID that we would need to keep around only for this purpose.
(A follow-up patch removes power well IDs not needed for direct power
 well access).

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index f1742466436d..f119cbe4f61d 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1045,8 +1045,6 @@ static void vlv_display_power_well_deinit(struct 
drm_i915_private *dev_priv)
 static void vlv_display_power_well_enable(struct drm_i915_private *dev_priv,
  struct i915_power_well *power_well)
 {
-   WARN_ON_ONCE(power_well->id != PUNIT_POWER_WELL_DISP2D);
-
vlv_set_power_well(dev_priv, power_well, true);
 
vlv_display_power_well_init(dev_priv);
@@ -1055,8 +1053,6 @@ static void vlv_display_power_well_enable(struct 
drm_i915_private *dev_priv,
 static void vlv_display_power_well_disable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   WARN_ON_ONCE(power_well->id != PUNIT_POWER_WELL_DISP2D);
-
vlv_display_power_well_deinit(dev_priv);
 
vlv_set_power_well(dev_priv, power_well, false);
@@ -1065,8 +1061,6 @@ static void vlv_display_power_well_disable(struct 
drm_i915_private *dev_priv,
 static void vlv_dpio_cmn_power_well_enable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   WARN_ON_ONCE(power_well->id != PUNIT_POWER_WELL_DPIO_CMN_BC);
-
/* since ref/cri clock was enabled */
udelay(1); /* >10ns for cmnreset, >0ns for sidereset */
 
@@ -1091,8 +1085,6 @@ static void vlv_dpio_cmn_power_well_disable(struct 
drm_i915_private *dev_priv,
 {
enum pipe pipe;
 
-   WARN_ON_ONCE(power_well->id != PUNIT_POWER_WELL_DPIO_CMN_BC);
-
for_each_pipe(dev_priv, pipe)
assert_pll_disabled(dev_priv, pipe);
 
@@ -1516,8 +1508,6 @@ static void chv_set_pipe_power_well(struct 
drm_i915_private *dev_priv,
 static void chv_pipe_power_well_enable(struct drm_i915_private *dev_priv,
   struct i915_power_well *power_well)
 {
-   WARN_ON_ONCE(power_well->id != CHV_DISP_PW_PIPE_A);
-
chv_set_pipe_power_well(dev_priv, power_well, true);
 
vlv_display_power_well_init(dev_priv);
@@ -1526,8 +1516,6 @@ static void chv_pipe_power_well_enable(struct 
drm_i915_private *dev_priv,
 static void chv_pipe_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
 {
-   WARN_ON_ONCE(power_well->id != CHV_DISP_PW_PIPE_A);
-
vlv_display_power_well_deinit(dev_priv);
 
chv_set_pipe_power_well(dev_priv, power_well, false);
-- 
2.13.2

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

[Intel-gfx] [PATCH 04/10] drm/i915: Constify power well descriptors

[Imre Deak]

It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of these objects their corresponding
i915_power_well_desc object.

Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_debugfs.c |   4 +-
 drivers/gpu/drm/i915/i915_drv.c |   8 +-
 drivers/gpu/drm/i915/i915_drv.h |  14 ++-
 drivers/gpu/drm/i915/intel_display.h|   4 +-
 drivers/gpu/drm/i915/intel_drv.h|   1 +
 drivers/gpu/drm/i915/intel_hdcp.c   |   6 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c | 204 +++-
 7 files changed, 144 insertions(+), 97 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index b3aefd623557..eb284cac8fda 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2833,10 +2833,10 @@ static int i915_power_domain_info(struct seq_file *m, 
void *unused)
enum intel_display_power_domain power_domain;
 
power_well = _domains->power_wells[i];
-   seq_printf(m, "%-25s %d\n", power_well->name,
+   seq_printf(m, "%-25s %d\n", power_well->desc->name,
   power_well->count);
 
-   for_each_power_domain(power_domain, power_well->domains)
+   for_each_power_domain(power_domain, power_well->desc->domains)
seq_printf(m, "  %-23s %d\n",
 intel_display_power_domain_str(power_domain),
 power_domains->domain_use_count[power_domain]);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3c984530fef9..5743db4500fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -922,7 +922,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
intel_uc_init_early(dev_priv);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
-   intel_power_domains_init(dev_priv);
+   ret = intel_power_domains_init(dev_priv);
+   if (ret < 0)
+   goto err_uc;
intel_irq_init(dev_priv);
intel_hangcheck_init(dev_priv);
intel_init_display_hooks(dev_priv);
@@ -934,6 +936,9 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 
return 0;
 
+err_uc:
+   intel_uc_cleanup_early(dev_priv);
+   i915_gem_cleanup_early(dev_priv);
 err_workqueues:
i915_workqueues_cleanup(dev_priv);
 err_engines:
@@ -948,6 +953,7 @@ static int i915_driver_init_early(struct drm_i915_private 
*dev_priv,
 static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
 {
intel_irq_fini(dev_priv);
+   intel_power_domains_cleanup(dev_priv);
intel_uc_cleanup_early(dev_priv);
i915_gem_cleanup_early(dev_priv);
i915_workqueues_cleanup(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4fb937399440..3ae200a9e8f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -862,13 +862,9 @@ struct i915_power_well_ops {
 };
 
 /* Power well structure for haswell */
-struct i915_power_well {
+struct i915_power_well_desc {
const char *name;
bool always_on;
-   /* power well enable/disable usage count */
-   int count;
-   /* cached hw enabled state */
-   bool hw_enabled;
u64 domains;
/* unique identifier for this power well */
enum i915_power_well_id id;
@@ -891,6 +887,14 @@ struct i915_power_well {
const struct i915_power_well_ops *ops;
 };
 
+struct i915_power_well {
+   const struct i915_power_well_desc *desc;
+   /* power well enable/disable usage count */
+   int count;
+   /* cached hw enabled state */
+   bool hw_enabled;
+};
+
 struct i915_power_domains {
/*
 * Power wells needed for initialization at driver init and suspend
diff --git a/drivers/gpu/drm/i915/intel_display.h 
b/drivers/gpu/drm/i915/intel_display.h
index 9292001cdd14..a626282d590b 100644
--- a/drivers/gpu/drm/i915/intel_display.h
+++ b/drivers/gpu/drm/i915/intel_display.h
@@ -322,11 +322,11 @@ struct intel_link_m_n {
 
 #define for_each_power_domain_well(__dev_priv, __power_well, __domain_mask)
\
for_each_power_well(__dev_priv, __power_well)   
\
-   for_each_if((__power_well)->domains & (__domain_mask))
+   for_each_if((__power_well)->desc->domains & (__domain_mask))
 
 #define for_each_power_domain_well_rev(__dev_priv, __power_well, 
__domain_mask) \
for_each_power_well_rev(__dev_priv, __power_well)   
\
-   

[Intel-gfx] [PATCH 01/10] drm/i915/icl: Fix power well anonymous union initializers

[Imre Deak]

Similarly to
0a445945be6d ("drm/i915: Work around GCC anonymous union initialization bug")
we need to initialize anonymous unions inside extra braces to work
around a GCC4.4 build error.

Cc: Chris Wilson 
Cc: Ville Syrjala 
Cc: Paulo Zanoni 
Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_runtime_pm.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6b5aa3b074ec..1a87176a85c1 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -2620,14 +2620,18 @@ static struct i915_power_well icl_power_wells[] = {
.domains = 0,
.ops = _power_well_ops,
.id = ICL_DISP_PW_1,
-   .hsw.has_fuses = true,
+   {
+   .hsw.has_fuses = true,
+   },
},
{
.name = "power well 2",
.domains = ICL_PW_2_POWER_DOMAINS,
.ops = _power_well_ops,
.id = ICL_DISP_PW_2,
-   .hsw.has_fuses = true,
+   {
+   .hsw.has_fuses = true,
+   },
},
{
.name = "DC off",
@@ -2640,9 +2644,11 @@ static struct i915_power_well icl_power_wells[] = {
.domains = ICL_PW_3_POWER_DOMAINS,
.ops = _power_well_ops,
.id = ICL_DISP_PW_3,
-   .hsw.irq_pipe_mask = BIT(PIPE_B),
-   .hsw.has_vga = true,
-   .hsw.has_fuses = true,
+   {
+   .hsw.irq_pipe_mask = BIT(PIPE_B),
+   .hsw.has_vga = true,
+   .hsw.has_fuses = true,
+   },
},
{
.name = "DDI A IO",
@@ -2745,8 +2751,10 @@ static struct i915_power_well icl_power_wells[] = {
.domains = ICL_PW_4_POWER_DOMAINS,
.ops = _power_well_ops,
.id = ICL_DISP_PW_4,
-   .hsw.has_fuses = true,
-   .hsw.irq_pipe_mask = BIT(PIPE_C),
+   {
+   .hsw.has_fuses = true,
+   .hsw.irq_pipe_mask = BIT(PIPE_C),
+   },
},
 };
 
-- 
2.13.2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on 
incorrect GuC pin bias
URL   : https://patchwork.freedesktop.org/series/46949/
State : failure

== Summary ==

= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9733 =

== Summary - FAILURE ==

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@drv_module_reload@basic-reload:
  {fi-skl-iommu}: PASS -> FAIL

igt@drv_selftest@live_guc:
  fi-kbl-7567u:   PASS -> DMESG-WARN
  fi-skl-gvtdvm:  PASS -> DMESG-WARN
  fi-bxt-dsi: PASS -> DMESG-WARN
  fi-whl-u:   PASS -> DMESG-WARN
  fi-kbl-7560u:   PASS -> DMESG-WARN
  {fi-kbl-8809g}: PASS -> DMESG-WARN
  fi-kbl-r:   PASS -> DMESG-WARN
  fi-kbl-x1275:   PASS -> DMESG-WARN
  fi-bxt-j4205:   PASS -> DMESG-WARN
  fi-cfl-s3:  PASS -> DMESG-WARN
  {fi-cfl-8109u}: PASS -> DMESG-WARN
  fi-kbl-7500u:   PASS -> DMESG-WARN
  fi-cfl-8700k:   PASS -> DMESG-WARN

igt@drv_selftest@live_hangcheck:
  fi-bxt-dsi: PASS -> DMESG-FAIL
  fi-bxt-j4205:   PASS -> DMESG-FAIL

igt@drv_selftest@live_requests:
  fi-bsw-n3050:   PASS -> INCOMPLETE


== Known issues ==

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

  === IGT changes ===

 Issues hit 

igt@drv_selftest@live_guc:
  fi-skl-6600u:   PASS -> DMESG-WARN (fdo#107175)
  {fi-skl-iommu}: PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6260u:   PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6700k2:  PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6770hq:  PASS -> DMESG-WARN (fdo#107175)
  fi-skl-6700hq:  PASS -> DMESG-WARN (fdo#107175)

igt@drv_selftest@live_hangcheck:
  {fi-skl-iommu}: PASS -> DMESG-FAIL (fdo#107174)

igt@drv_selftest@live_workarounds:
  fi-bsw-n3050:   PASS -> DMESG-FAIL (fdo#107292)


 Possible fixes 

igt@drv_selftest@live_hangcheck:
  fi-skl-guc: DMESG-FAIL (fdo#107174) -> PASS

igt@drv_selftest@live_workarounds:
  {fi-cfl-8109u}: DMESG-FAIL (fdo#107292) -> PASS


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).

  fdo#107174 https://bugs.freedesktop.org/show_bug.cgi?id=107174
  fdo#107175 https://bugs.freedesktop.org/show_bug.cgi?id=107175
  fdo#107292 https://bugs.freedesktop.org/show_bug.cgi?id=107292


== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4518 -> Patchwork_9733

  CI_DRM_4518: 85bdcb875339b30f7beecbc7cba6bc2041cdd28b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9733: c7c7c3ad0242a2f6dd205940678ee8dfa8cd533b @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

c7c7c3ad0242 HAX enable GuC for CI
247c621df7b4 drm/i915: Add a fault injection point to WOPCM init
7a035ce3cb07 drm/i915: Remove unnecessary ggtt_offset_bias from i915_gem_context
941307b4db54 drm/i915/guc: Move the pin bias value from GuC to GGTT
a2a959a0098d drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

== Logs ==

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

[Intel-gfx] [PATCH i-g-t] lib/pm: Fix some runtime PM issues

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

1.

It seems that on many systems the hardcoded PCI path in
igt_pm_audio_setup_runtime_pm is not correct.

Add some more paths to work around the issue. More robust solution would
be to look for a symlink of a specific format and use that, such as:

 # ls -ld /sys/bus/pci/drivers/snd_hda_intel/\:00\:1f.3/
 drwxr-xr-x 7 root root 0 Jul 20 14:48 
/sys/bus/pci/drivers/snd_hda_intel/:00:1f.3/

But that's more work, so leave it for a rainy day.

2.

Cleanup handlers were not signal safe - rewrite them.

3.

Along the way I can also export the explicit cleanup function to be called
from individual test cases where that is wanted.

4.

Call the cleanup explicitly from perf_pmu/rc6-runtime-pm.

v2:
 * Skip double restore. (Chris Wilson)
 * Close previously leaked fd.

v3:
 * Refactor atexit handlers to be signal safe. (Chris Wilson)
 * Restore audio runtime PM status.
 * Add a different PCI path to audio device.

v4:
 * Patch renamed and commit message improved.
 * Add another possible PCI bus location.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Reviewed-by: Chris Wilson  # v3
---
Dear Santa,

Please don't make this split this up - at least not today since it is
Friday and an unusually warm day! :)
---
 lib/igt_pm.c | 153 ---
 lib/igt_pm.h |   1 +
 tests/perf_pmu.c |   3 +
 3 files changed, 123 insertions(+), 34 deletions(-)

diff --git a/lib/igt_pm.c b/lib/igt_pm.c
index 8ac132269d79..18c5eef9a43b 100644
--- a/lib/igt_pm.c
+++ b/lib/igt_pm.c
@@ -63,36 +63,74 @@ enum {
 /* Remember to fix this if adding longer strings */
 #define MAX_POLICY_STRLEN  strlen(MAX_PERFORMANCE_STR)
 
+static const char *const __igt_pm_audio_runtime_control_paths[] = {
+   "/sys/bus/pci/devices/:00:02.0/power/control",
+   "/sys/bus/pci/devices/:00:03.0/power/control",
+   "/sys/bus/pci/devices/:00:1f.3/power/control",
+};
+
 static char __igt_pm_audio_runtime_power_save[64];
+static const char * __igt_pm_audio_runtime_control_path;
 static char __igt_pm_audio_runtime_control[64];
 
-static void __igt_pm_audio_runtime_exit_handler(int sig)
+static int __igt_pm_audio_restore_runtime_pm(void)
 {
int fd;
 
-   igt_debug("Restoring audio power management to '%s' and '%s'\n",
- __igt_pm_audio_runtime_power_save,
- __igt_pm_audio_runtime_control);
+   if (!__igt_pm_audio_runtime_power_save[0])
+   return 0;
 
fd = open("/sys/module/snd_hda_intel/parameters/power_save", O_WRONLY);
if (fd < 0)
-   return;
+   return errno;
+
if (write(fd, __igt_pm_audio_runtime_power_save,
  strlen(__igt_pm_audio_runtime_power_save)) !=
-   strlen(__igt_pm_audio_runtime_power_save))
-   igt_warn("Failed to restore audio power_save to '%s'\n",
-__igt_pm_audio_runtime_power_save);
+   strlen(__igt_pm_audio_runtime_power_save)) {
+   close(fd);
+   return errno;
+   }
+
close(fd);
 
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_WRONLY);
+   fd = open(__igt_pm_audio_runtime_control_path, O_WRONLY);
if (fd < 0)
-   return;
+   return errno;
+
if (write(fd, __igt_pm_audio_runtime_control,
  strlen(__igt_pm_audio_runtime_control)) !=
-   strlen(__igt_pm_audio_runtime_control))
-   igt_warn("Failed to restore audio control to '%s'\n",
-__igt_pm_audio_runtime_control);
+   strlen(__igt_pm_audio_runtime_control)) {
+   close(fd);
+   return errno;
+   }
+
close(fd);
+
+   __igt_pm_audio_runtime_power_save[0] = 0;
+
+   return 0;
+}
+
+static void igt_pm_audio_restore_runtime_pm(void)
+{
+   int ret;
+
+   if (!__igt_pm_audio_runtime_power_save[0])
+   return;
+
+   igt_debug("Restoring audio power management to '%s' and '%s'\n",
+ __igt_pm_audio_runtime_power_save,
+ __igt_pm_audio_runtime_control);
+
+   ret = __igt_pm_audio_restore_runtime_pm();
+   if (ret)
+   igt_warn("Failed to restore runtime audio PM! (errno=%d)\n",
+ret);
+}
+
+static void __igt_pm_audio_runtime_exit_handler(int sig)
+{
+   __igt_pm_audio_restore_runtime_pm();
 }
 
 static void strchomp(char *str)
@@ -116,7 +154,7 @@ static void strchomp(char *str)
  */
 void igt_pm_enable_audio_runtime_pm(void)
 {
-   int fd;
+   int fd, i;
 
/* Check if already enabled. */
if (__igt_pm_audio_runtime_power_save[0])
@@ -131,14 +169,23 @@ void igt_pm_enable_audio_runtime_pm(void)
igt_assert_eq(write(fd, "1\n", 2), 2);
close(fd);
}
-   fd = open("/sys/bus/pci/devices/:00:03.0/power/control", O_RDWR);
-   if (fd >= 0) {
-   

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Ville Syrjälä (2018-07-20 14:50:25)
> On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > > Another question is what happens where there are parallel flips
> > > happening? One could undo the boost from the other AFAICS. But maybe
> > > we don't care enough to protect against that?
> > 
> > It's a counter, so the "interactive" mode remains high until all
> > concurrent flips are completed.
> 
> Ah. I guess the bool in the atomic state threw me off. I suppose that
> one is just an optimization to avoid calling the function more than
> once?

Yes, it's that I caught the RPS counter going negative. We have more
cleanup_plane than we prepared I believe that's from
find_initial_plane.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 14:29:52)
> 
> On 20/07/2018 14:02, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> >>
> >> On 12/07/2018 18:38, Chris Wilson wrote:
> >>> + if (rps->interactive)
> >>> + new_power = HIGH_POWER;
> >>> + rps_set_power(dev_priv, new_power);
> >>> + mutex_unlock(>power_lock);
> >>   >
> >>   >  rps->last_adj = 0;
> >>
> >> This block should go up to the beginning of the function since when
> >> rps->interactive all preceding calculations are for nothing. And can
> >> immediately return then.
> > 
> > We have to lock around rps_set_power, so you're not going to avoid
> > taking the lock here, so I don't think it makes any difference.
> > Certainly neater than locking everything.
> 
> Not to avoid the lock but to avoid all the trouble of calculating 
> new_power to override it all if rps->interactive is set. Just looks a 
> bit weird. I suspect read of rps->interactive doesn't even need to be 
> under the lock so maybe:
> 
> if (rps->interactive)
> new_power = HIGH_POWER;
> } else {
> switch (...)
> }

There is a race there, so you do need to explain why we wouldn't care.
(There is a reasonable argument about it being periodic and we don't care
about the first vs interactive.) I thought it came out quite neat as the
atomic override.

> >>> +{
> >>> + struct intel_rps *rps = _priv->gt_pm.rps;
> >>> +
> >>> + if (INTEL_GEN(dev_priv) < 6)
> >>> + return;
> >>> +
> >>> + mutex_lock(>power_lock);
> >>> + if (state) {
> >>> + if (!rps->interactive++ && READ_ONCE(dev_priv->gt.awake))
> >>> + rps_set_power(dev_priv, HIGH_POWER);
> >>> + } else {
> >>> + GEM_BUG_ON(!rps->interactive);
> >>> + rps->interactive--;
> >>
> >> Hm maybe protect this in production code so some missed code flows in
> >> the atomic paths do not cause underflow and so permanent interactive mode.
> > 
> > Are you suggesting testing is inadequate? ;) Underflow here isn't a big
> > deal, it just locks in the HIGH_POWER (faster sampling, bias towards
> > upclocking). Or worse not allow HIGH_POWER, status quo returned.
> 
> Testing for this probably is inadequate, no? Would need to be looking at 
> the new debugfs flag from many test cases. And in real world probably 
> quite difficult to debug too.
> 
> Whether or not it would be too much to add a DRM_WARN for this.. I am 
> leaning towards saying to have it, since it is about two systems 
> communicating together so it would be easier to notice a broken 
> contract. But I don't insist on it.

Just checking underflow is not going to catch many problems. If we can
identify some points where we know what the value should be... I wonder
if we can assert it is zero at runtime/system suspend.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Ville Syrjälä]

On Fri, Jul 20, 2018 at 02:38:32PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:32:40)
> > On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> > > Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > > > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> > > > Doing this kind of global thing from the plane hooks seems a bit
> > > > strange. How about just doing this directly from commit_tail()
> > > > etc.?
> > > 
> > > We want it upfront in prepare (so that it's set before any wait) or
> > > somewhere around there (atomic_state setup?). cleanup was chosen for the
> > > symmetry with prepare.
> > 
> > Looks like we have intel_atomic_prepare_commit() which I guess would be
> > a decent spot then. And introduce intel_atomic_cleanup_commit() to do
> > the reverse?
> 
> The only other point is I started from prepare_plane for being next to
> both the reprioritisation and the add_rps_boost_after_vblank. So that's
> quite nice.

Ok, I guess that's quite reasonable.

>  
> > Another question is what happens where there are parallel flips
> > happening? One could undo the boost from the other AFAICS. But maybe
> > we don't care enough to protect against that?
> 
> It's a counter, so the "interactive" mode remains high until all
> concurrent flips are completed.

Ah. I guess the bool in the atomic state threw me off. I suppose that
one is just an optimization to avoid calling the function more than
once?

-- 
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.SPARSE: warning for series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

[Patchwork]

== Series Details ==

Series: series starting with [v4,1/5] drm/i915/guc: Avoid wasting memory on 
incorrect GuC pin bias
URL   : https://patchwork.freedesktop.org/series/46949/
State : warning

== Summary ==

$ dim sparse origin/drm-tip
Commit: drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias
Okay!

Commit: drm/i915/guc: Move the pin bias value from GuC to GGTT
+drivers/gpu/drm/i915/i915_gem_gtt.c:2937:26: warning: expression using 
sizeof(void)

Commit: drm/i915: Remove unnecessary ggtt_offset_bias from i915_gem_context
Okay!

Commit: drm/i915: Add a fault injection point to WOPCM init
Okay!

Commit: HAX enable GuC for CI
Okay!

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Ville Syrjälä (2018-07-20 14:32:40)
> On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> > > Doing this kind of global thing from the plane hooks seems a bit
> > > strange. How about just doing this directly from commit_tail()
> > > etc.?
> > 
> > We want it upfront in prepare (so that it's set before any wait) or
> > somewhere around there (atomic_state setup?). cleanup was chosen for the
> > symmetry with prepare.
> 
> Looks like we have intel_atomic_prepare_commit() which I guess would be
> a decent spot then. And introduce intel_atomic_cleanup_commit() to do
> the reverse?

The only other point is I started from prepare_plane for being next to
both the reprioritisation and the add_rps_boost_after_vblank. So that's
quite nice.
 
> Another question is what happens where there are parallel flips
> happening? One could undo the boost from the other AFAICS. But maybe
> we don't care enough to protect against that?

It's a counter, so the "interactive" mode remains high until all
concurrent flips are completed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 2/5] drm/i915/guc: Move the pin bias value from GuC to GGTT

[Jakub Bartmiński]

Removing the pin bias from GuC allows us to not check for GuC every time
we pin a context, which fixes the assertion error on unresolved GuC
platform default in mock contexts selftest.

It also seems that we were using uninitialized WOPCM variables when
setting the GuC pin bias. The pin bias has to be set after the WOPCM,
but before the call to i915_gem_contexts_init where the first contexts
are pinned.

v2:
This also makes it so that there's no need to set GuC variables from
within the WOPCM init function or to move the WOPCM init, while keeping
the correct initialization order. Also for mock tests the pin bias is
left at 0 and we make sure that the pin bias with GuC will not be
smaller than without GuC.

v3:
Avoid unused i915 in intel_guc_ggtt_offset if debug is disabled.

v4:
Squash with WOPCM init reordering.
Moved the i915_ggtt_pin_bias helper to this patch, and made some
functions use it instead of directly dereferencing i915->ggtt.

Fixes: f7dc0157e4b5 ("drm/i915/uc: Fetch GuC/HuC firmwares from guc/huc 
specific init")
Testcase: igt/drv_selftest/mock_contexts #GuC
Signed-off-by: Jakub Bartmiński 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 22 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 18 ++
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 ++
 drivers/gpu/drm/i915/i915_vma.h |  5 
 drivers/gpu/drm/i915/intel_guc.c| 33 +
 drivers/gpu/drm/i915/intel_guc.h| 11 +++--
 drivers/gpu/drm/i915/intel_huc.c|  2 +-
 drivers/gpu/drm/i915/intel_uc_fw.c  |  2 +-
 drivers/gpu/drm/i915/intel_wopcm.h  | 18 ++
 9 files changed, 57 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index b10770cfccd2..ae27caad1766 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -265,7 +265,7 @@ static u32 default_desc_template(const struct 
drm_i915_private *i915,
 }
 
 static struct i915_gem_context *
-__create_hw_context(struct drm_i915_private *dev_priv,
+__create_hw_context(struct drm_i915_private *i915,
struct drm_i915_file_private *file_priv)
 {
struct i915_gem_context *ctx;
@@ -276,15 +276,15 @@ __create_hw_context(struct drm_i915_private *dev_priv,
if (ctx == NULL)
return ERR_PTR(-ENOMEM);
 
-   ret = assign_hw_id(dev_priv, >hw_id);
+   ret = assign_hw_id(i915, >hw_id);
if (ret) {
kfree(ctx);
return ERR_PTR(ret);
}
 
kref_init(>ref);
-   list_add_tail(>link, _priv->contexts.list);
-   ctx->i915 = dev_priv;
+   list_add_tail(>link, >contexts.list);
+   ctx->i915 = i915;
ctx->sched.priority = I915_PRIORITY_NORMAL;
 
for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
@@ -322,22 +322,14 @@ __create_hw_context(struct drm_i915_private *dev_priv,
/* NB: Mark all slices as needing a remap so that when the context first
 * loads it will restore whatever remap state already exists. If there
 * is no remap info, it will be a NOP. */
-   ctx->remap_slice = ALL_L3_SLICES(dev_priv);
+   ctx->remap_slice = ALL_L3_SLICES(i915);
 
i915_gem_context_set_bannable(ctx);
ctx->ring_size = 4 * PAGE_SIZE;
ctx->desc_template =
-   default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
+   default_desc_template(i915, i915->mm.aliasing_ppgtt);
 
-   /*
-* GuC requires the ring to be placed in Non-WOPCM memory. If GuC is not
-* present or not in use we still need a small bias as ring wraparound
-* at offset 0 sometimes hangs. No idea why.
-*/
-   if (USES_GUC(dev_priv))
-   ctx->ggtt_offset_bias = dev_priv->guc.ggtt_pin_bias;
-   else
-   ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
+   ctx->ggtt_offset_bias = i915->ggtt.pin_bias;
 
return ctx;
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index d0acef299b9c..1f5d0334f0f5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2901,7 +2901,7 @@ void i915_gem_fini_aliasing_ppgtt(struct drm_i915_private 
*i915)
ggtt->vm.vma_ops.unbind_vma = ggtt_unbind_vma;
 }
 
-int i915_gem_init_ggtt(struct drm_i915_private *dev_priv)
+int i915_gem_init_ggtt(struct drm_i915_private *i915)
 {
/* Let GEM Manage all of the aperture.
 *
@@ -2912,12 +2912,20 @@ int i915_gem_init_ggtt(struct drm_i915_private 
*dev_priv)
 * aperture.  One page should be enough to keep any prefetching inside
 * of the aperture.
 */
-   struct i915_ggtt *ggtt = _priv->ggtt;
+   struct i915_ggtt *ggtt = >ggtt;
unsigned long hole_start, hole_end;
struct drm_mm_node *entry;
int ret;

[Intel-gfx] [PATCH v4 3/5] drm/i915: Remove unnecessary ggtt_offset_bias from i915_gem_context

[Jakub Bartmiński]

Since ggtt_offset_bias is now stored in ggtt.pin_bias, it is duplicated
inside i915_gem_context, and can instead be accessed directly from ggtt.

v3:
Added a helper function to retrieve the ggtt.pin_bias from the vma.

v4:
Moved the helper function to the previous patch in the series.
Dropped the bias from intel_ring_pin. This introduces a slight functional
change since we are always pinning a ring a bit higher if GuC is present
even though we don't really need to.

Signed-off-by: Jakub Bartmiński 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_gem_context.c |  2 --
 drivers/gpu/drm/i915/i915_gem_context.h |  3 ---
 drivers/gpu/drm/i915/intel_lrc.c|  6 ++
 drivers/gpu/drm/i915/intel_ringbuffer.c | 14 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 +---
 5 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index ae27caad1766..6067563750de 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -329,8 +329,6 @@ __create_hw_context(struct drm_i915_private *i915,
ctx->desc_template =
default_desc_template(i915, i915->mm.aliasing_ppgtt);
 
-   ctx->ggtt_offset_bias = i915->ggtt.pin_bias;
-
return ctx;
 
 err_pid:
diff --git a/drivers/gpu/drm/i915/i915_gem_context.h 
b/drivers/gpu/drm/i915/i915_gem_context.h
index b116e4942c10..851dad6decd7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.h
+++ b/drivers/gpu/drm/i915/i915_gem_context.h
@@ -147,9 +147,6 @@ struct i915_gem_context {
 
struct i915_sched_attr sched;
 
-   /** ggtt_offset_bias: placement restriction for context objects */
-   u32 ggtt_offset_bias;
-
/** engine: per-engine logical HW state */
struct intel_context {
struct i915_gem_context *gem_context;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 35d37af0cb9a..c923eb998c28 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1363,9 +1363,7 @@ static int __context_pin(struct i915_gem_context *ctx, 
struct i915_vma *vma)
}
 
flags = PIN_GLOBAL | PIN_HIGH;
-   if (ctx->ggtt_offset_bias)
-   flags |= PIN_OFFSET_BIAS | ctx->ggtt_offset_bias;
-
+   flags |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
return i915_vma_pin(vma, 0, GEN8_LR_CONTEXT_ALIGN, flags);
 }
 
@@ -1392,7 +1390,7 @@ __execlists_context_pin(struct intel_engine_cs *engine,
goto unpin_vma;
}
 
-   ret = intel_ring_pin(ce->ring, ctx->i915, ctx->ggtt_offset_bias);
+   ret = intel_ring_pin(ce->ring, ctx->i915);
if (ret)
goto unpin_map;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index f4bd185c9369..8a48325249a3 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1005,9 +1005,7 @@ i915_emit_bb_start(struct i915_request *rq,
 
 
 
-int intel_ring_pin(struct intel_ring *ring,
-  struct drm_i915_private *i915,
-  unsigned int offset_bias)
+int intel_ring_pin(struct intel_ring *ring, struct drm_i915_private *i915)
 {
enum i915_map_type map = HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
struct i915_vma *vma = ring->vma;
@@ -1017,10 +1015,11 @@ int intel_ring_pin(struct intel_ring *ring,
 
GEM_BUG_ON(ring->vaddr);
 
-
flags = PIN_GLOBAL;
-   if (offset_bias)
-   flags |= PIN_OFFSET_BIAS | offset_bias;
+
+   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
+   flags |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
+
if (vma->obj->stolen)
flags |= PIN_MAPPABLE;
else
@@ -1404,8 +1403,7 @@ static int intel_init_ring_buffer(struct intel_engine_cs 
*engine)
goto err;
}
 
-   /* Ring wraparound at offset 0 sometimes hangs. No idea why. */
-   err = intel_ring_pin(ring, engine->i915, I915_GTT_PAGE_SIZE);
+   err = intel_ring_pin(ring, engine->i915);
if (err)
goto err_ring;
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index d1eee08e5f6b..7fe07b2de2a7 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -784,9 +784,7 @@ struct intel_ring *
 intel_engine_create_ring(struct intel_engine_cs *engine,
 struct i915_timeline *timeline,
 int size);
-int intel_ring_pin(struct intel_ring *ring,
-  struct drm_i915_private *i915,
-  unsigned int offset_bias);
+int intel_ring_pin(struct intel_ring *ring, struct drm_i915_private *i915);
 void intel_ring_reset(struct intel_ring *ring, u32 tail);
 unsigned int intel_ring_update_space(struct 

[Intel-gfx] [PATCH v4 5/5] HAX enable GuC for CI

[Jakub Bartmiński]

From: Michal Wajdeczko 

Signed-off-by: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/i915_params.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index aebe0469ddaa..3e4e128237ac 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -47,7 +47,7 @@ struct drm_printer;
param(int, disable_power_well, -1) \
param(int, enable_ips, 1) \
param(int, invert_brightness, 0) \
-   param(int, enable_guc, 0) \
+   param(int, enable_guc, -1) \
param(int, guc_log_level, -1) \
param(char *, guc_firmware_path, NULL) \
param(char *, huc_firmware_path, NULL) \
-- 
2.17.1

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

[Intel-gfx] [PATCH v4 4/5] drm/i915: Add a fault injection point to WOPCM init

[Jakub Bartmiński]

v4:
Move the injection inside the WOPCM init.

Signed-off-by: Jakub Bartmiński 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_wopcm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_wopcm.c 
b/drivers/gpu/drm/i915/intel_wopcm.c
index 74bf76f3fddc..86c38b072926 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -165,6 +165,9 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
 
GEM_BUG_ON(!wopcm->size);
 
+   if (i915_inject_load_failure())
+   return -E2BIG;
+
if (guc_fw_size >= wopcm->size) {
DRM_ERROR("GuC FW (%uKiB) is too big to fit in WOPCM.",
  guc_fw_size / 1024);
-- 
2.17.1

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

[Intel-gfx] [PATCH v4 1/5] drm/i915/guc: Avoid wasting memory on incorrect GuC pin bias

[Jakub Bartmiński]

It would appear that the calculated GuC pin bias was larger than it
should be, as the GuC address space does NOT contain the "HW contexts RSVD"
part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size.

Signed-off-by: Jakub Bartmiński 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michal Wajdeczko 
---
 drivers/gpu/drm/i915/intel_guc.c | 50 ++--
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c
index e12bd259df17..17753952933e 100644
--- a/drivers/gpu/drm/i915/intel_guc.c
+++ b/drivers/gpu/drm/i915/intel_guc.c
@@ -582,50 +582,44 @@ int intel_guc_resume(struct intel_guc *guc)
  *
  * ::
  *
- * +==> ++ <== GUC_GGTT_TOP
- * ^||
- * |||
- * ||DRAM|
- * ||   Memory   |
- * |||
- *GuC   ||
- *  Address  +> ++ <== WOPCM Top
- *   Space   ^  |   HW contexts RSVD |
- * | |  |WOPCM   |
- * | | +==> ++ <== GuC WOPCM Top
- * |GuC^||
- * |GGTT   |||
- * |Pin   GuC   |GuC |
- * |Bias WOPCM  |   WOPCM|
- * | |Size  ||
- * | | |||
- * v v v||
- * +=+=+==> ++ <== GuC WOPCM Base
- *  |   Non-GuC WOPCM|
- *  |   (HuC/Reserved)   |
- *  ++ <== WOPCM Base
+ * +> ++ <== GUC_GGTT_TOP
+ * ^  ||
+ * |  ||
+ * |  |DRAM|
+ * |  |   Memory   |
+ * |  ||
+ *GuC ||
+ *  Address+> ++ <== GuC WOPCM Top
+ *   Space ^  ||
+ * |   |  ||
+ * |  GuC |GuC |
+ * | WOPCM|   WOPCM|
+ * |  Size||
+ * |   |  ||
+ * v   v  ||
+ * +===+> ++ <== GuC WOPCM Base
  *
  * The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped to WOPCM
  * while upper part of GuC Address Space [ggtt_pin_bias, GUC_GGTT_TOP) is 
mapped
- * to DRAM. The value of the GuC ggtt_pin_bias is determined by WOPCM size and
- * actual GuC WOPCM size.
+ * to DRAM. The value of the GuC ggtt_pin_bias is the GuC WOPCM size.
  */
 
 /**
  * guc_init_ggtt_pin_bias() - Initialize the GuC ggtt_pin_bias value.
  * @guc: intel_guc structure.
  *
- * This function will calculate and initialize the ggtt_pin_bias value based on
- * overall WOPCM size and GuC WOPCM size.
+ * This function will calculate and initialize the ggtt_pin_bias value
+ * based on the GuC WOPCM size.
  */
 static void guc_init_ggtt_pin_bias(struct intel_guc *guc)
 {
struct drm_i915_private *i915 = guc_to_i915(guc);
 
GEM_BUG_ON(!i915->wopcm.size);
-   GEM_BUG_ON(i915->wopcm.size < i915->wopcm.guc.base);
+   GEM_BUG_ON(range_overflows(i915->wopcm.guc.base, i915->wopcm.guc.size,
+  i915->wopcm.size));
 
-   guc->ggtt_pin_bias = i915->wopcm.size - i915->wopcm.guc.base;
+   guc->ggtt_pin_bias = i915->wopcm.guc.size;
 }
 
 /**
-- 
2.17.1

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Ville Syrjälä]

On Fri, Jul 20, 2018 at 02:14:11PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2018-07-20 14:07:31)
> > On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> > Doing this kind of global thing from the plane hooks seems a bit
> > strange. How about just doing this directly from commit_tail()
> > etc.?
> 
> We want it upfront in prepare (so that it's set before any wait) or
> somewhere around there (atomic_state setup?). cleanup was chosen for the
> symmetry with prepare.

Looks like we have intel_atomic_prepare_commit() which I guess would be
a decent spot then. And introduce intel_atomic_cleanup_commit() to do
the reverse?

Another question is what happens where there are parallel flips
happening? One could undo the boost from the other AFAICS. But maybe
we don't care enough to protect against that?

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Tvrtko Ursulin]

On 20/07/2018 14:02, Chris Wilson wrote:

Quoting Tvrtko Ursulin (2018-07-20 13:49:09)


On 12/07/2018 18:38, Chris Wilson wrote:

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7998e70a3174..5809366ff9f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13104,6 +13104,19 @@ intel_prepare_plane_fb(struct drm_plane *plane,
   add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
   }
   
+ /*

+  * We declare pageflips to be interactive and so merit a small bias
+  * towards upclocking to deliver the frame on time. By only changing
+  * the RPS thresholds to sample more regularly and aim for higher
+  * clocks we can hopefully deliver low power workloads (like kodi)
+  * that are not quite steady state without resorting to forcing
+  * maximum clocks following a vblank miss (see do_rps_boost()).
+  */
+ if (!intel_state->rps_interactive) {
+ intel_rps_set_interactive(dev_priv, true);
+ intel_state->rps_interactive = true;
+ }
+
   return 0;
   }
   
@@ -13120,8 +13133,15 @@ void

   intel_cleanup_plane_fb(struct drm_plane *plane,
  struct drm_plane_state *old_state)
   {
+ struct intel_atomic_state *intel_state =
+ to_intel_atomic_state(old_state->state);
   struct drm_i915_private *dev_priv = to_i915(plane->dev);
   
+ if (intel_state->rps_interactive) {

+ intel_rps_set_interactive(dev_priv, false);
+ intel_state->rps_interactive = false;
+ }


Why is the rps_intearctive flag needed in plane state? I wanted to
assume prepare & cleanup hooks are fully symmetric, but this flags makes
me unsure. A reviewer with more display knowledge will be needed here I
think.


It's so that when we call intel_cleanup_plane_fb() on something that
wasn't first prepared, we don't decrement the counter. There's a little
bit of asymmetry at the start where we inherit the plane state.


+
   /* Should only be called after a successful intel_prepare_plane_fb()! */
   mutex_lock(_priv->drm.struct_mutex);
   intel_plane_unpin_fb(to_intel_plane_state(old_state));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 61e715ddd0d5..544812488821 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -482,6 +482,8 @@ struct intel_atomic_state {
*/
   bool skip_intermediate_wm;
   
+ bool rps_interactive;


Should the name at this level be something more tied to the subsystem
and not implying wider relationships? Like page flip pending? fb_prepared?


But we are in the plane state so anything plane/flip is implied. I think
saying whether or not we've called out to rps is a reasonable name for
the state.


Okay fair enough. Maybe just call it rps_interactive_requested?


+ /* Max/min bins are special */
+ if (val <= rps->min_freq_softlimit)
+ new_power = LOW_POWER;
+ if (val >= rps->max_freq_softlimit)
+ new_power = HIGH_POWER;
+
+ mutex_lock(>power_lock);


Is it worth avoiding the atomic here when GEN < 6?


We don't get here when not !RPS. You mean GEN < 5 ;)


No, okay, just incomplete picture based on locking in the other helper. 
Ignore.



+ if (rps->interactive)
+ new_power = HIGH_POWER;
+ rps_set_power(dev_priv, new_power);
+ mutex_unlock(>power_lock);

  >
  >  rps->last_adj = 0;

This block should go up to the beginning of the function since when
rps->interactive all preceding calculations are for nothing. And can
immediately return then.


We have to lock around rps_set_power, so you're not going to avoid
taking the lock here, so I don't think it makes any difference.
Certainly neater than locking everything.


Not to avoid the lock but to avoid all the trouble of calculating 
new_power to override it all if rps->interactive is set. Just looks a 
bit weird. I suspect read of rps->interactive doesn't even need to be 
under the lock so maybe:


if (rps->interactive)
new_power = HIGH_POWER;
} else {
switch (...)
}

mutex_lock
...
mutex_unlock





+void intel_rps_set_interactive(struct drm_i915_private *dev_priv, bool state)


s/state/interactive/ for more self-documenting function body?

And not s/dev_priv/i915/ ?!? :)


+{
+ struct intel_rps *rps = _priv->gt_pm.rps;
+
+ if (INTEL_GEN(dev_priv) < 6)
+ return;
+
+ mutex_lock(>power_lock);
+ if (state) {
+ if (!rps->interactive++ && READ_ONCE(dev_priv->gt.awake))
+ rps_set_power(dev_priv, HIGH_POWER);
+ } else {
+ GEM_BUG_ON(!rps->interactive);
+ rps->interactive--;


Hm maybe protect this in production code so some missed code flows in
the atomic paths do not cause underflow and so permanent interactive mode.


Are you suggesting testing is inadequate? ;) 

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Ville Syrjälä (2018-07-20 14:07:31)
> On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> Doing this kind of global thing from the plane hooks seems a bit
> strange. How about just doing this directly from commit_tail()
> etc.?

We want it upfront in prepare (so that it's set before any wait) or
somewhere around there (atomic_state setup?). cleanup was chosen for the
symmetry with prepare.

Pick a spot for the increment for that tells us where to decrement.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Ville Syrjälä]

On Fri, Jul 20, 2018 at 02:02:34PM +0100, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> > 
> > On 12/07/2018 18:38, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 7998e70a3174..5809366ff9f0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -13104,6 +13104,19 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> > >   add_rps_boost_after_vblank(new_state->crtc, 
> > > new_state->fence);
> > >   }
> > >   
> > > + /*
> > > +  * We declare pageflips to be interactive and so merit a small bias
> > > +  * towards upclocking to deliver the frame on time. By only changing
> > > +  * the RPS thresholds to sample more regularly and aim for higher
> > > +  * clocks we can hopefully deliver low power workloads (like kodi)
> > > +  * that are not quite steady state without resorting to forcing
> > > +  * maximum clocks following a vblank miss (see do_rps_boost()).
> > > +  */
> > > + if (!intel_state->rps_interactive) {
> > > + intel_rps_set_interactive(dev_priv, true);
> > > + intel_state->rps_interactive = true;
> > > + }
> > > +
> > >   return 0;
> > >   }
> > >   
> > > @@ -13120,8 +13133,15 @@ void
> > >   intel_cleanup_plane_fb(struct drm_plane *plane,
> > >  struct drm_plane_state *old_state)
> > >   {
> > > + struct intel_atomic_state *intel_state =
> > > + to_intel_atomic_state(old_state->state);
> > >   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> > >   
> > > + if (intel_state->rps_interactive) {
> > > + intel_rps_set_interactive(dev_priv, false);
> > > + intel_state->rps_interactive = false;
> > > + }
> > 
> > Why is the rps_intearctive flag needed in plane state? I wanted to 
> > assume prepare & cleanup hooks are fully symmetric, but this flags makes 
> > me unsure. A reviewer with more display knowledge will be needed here I 
> > think.
> 
> It's so that when we call intel_cleanup_plane_fb() on something that
> wasn't first prepared, we don't decrement the counter. There's a little
> bit of asymmetry at the start where we inherit the plane state.

Doing this kind of global thing from the plane hooks seems a bit
strange. How about just doing this directly from commit_tail()
etc.?

-- 
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.BAT: success for drm/i915: Show stack (by WARN) for hitting forcewake errors

[Patchwork]

== Series Details ==

Series: drm/i915: Show stack (by WARN) for hitting forcewake errors
URL   : https://patchwork.freedesktop.org/series/46939/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_4518 -> Patchwork_9732 =

== Summary - SUCCESS ==

  No regressions found.

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

== Possible new issues ==

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

  === IGT changes ===

 Possible regressions 

igt@drv_selftest@live_hangcheck:
  {fi-cfl-8109u}: PASS -> DMESG-FAIL

igt@drv_selftest@live_hugepages:
  {fi-cfl-8109u}: PASS -> DMESG-WARN +9


  {name}: This element is suppressed. This means it is ignored when computing
  the status of the difference (SUCCESS, WARNING, or FAILURE).



== Participating hosts (47 -> 42) ==

  Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan 
fi-hsw-4200u 


== Build changes ==

* Linux: CI_DRM_4518 -> Patchwork_9732

  CI_DRM_4518: 85bdcb875339b30f7beecbc7cba6bc2041cdd28b @ 
git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4569: bf70728a951cd3c08dd9bbc9310e16aaa252164f @ 
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_9732: 2a9f353b3958cc8d481a9a8f13236184d789f1e7 @ 
git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

2a9f353b3958 drm/i915: Show stack (by WARN) for hitting forcewake errors

== Logs ==

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-07-20 13:49:09)
> 
> On 12/07/2018 18:38, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7998e70a3174..5809366ff9f0 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13104,6 +13104,19 @@ intel_prepare_plane_fb(struct drm_plane *plane,
> >   add_rps_boost_after_vblank(new_state->crtc, new_state->fence);
> >   }
> >   
> > + /*
> > +  * We declare pageflips to be interactive and so merit a small bias
> > +  * towards upclocking to deliver the frame on time. By only changing
> > +  * the RPS thresholds to sample more regularly and aim for higher
> > +  * clocks we can hopefully deliver low power workloads (like kodi)
> > +  * that are not quite steady state without resorting to forcing
> > +  * maximum clocks following a vblank miss (see do_rps_boost()).
> > +  */
> > + if (!intel_state->rps_interactive) {
> > + intel_rps_set_interactive(dev_priv, true);
> > + intel_state->rps_interactive = true;
> > + }
> > +
> >   return 0;
> >   }
> >   
> > @@ -13120,8 +13133,15 @@ void
> >   intel_cleanup_plane_fb(struct drm_plane *plane,
> >  struct drm_plane_state *old_state)
> >   {
> > + struct intel_atomic_state *intel_state =
> > + to_intel_atomic_state(old_state->state);
> >   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> >   
> > + if (intel_state->rps_interactive) {
> > + intel_rps_set_interactive(dev_priv, false);
> > + intel_state->rps_interactive = false;
> > + }
> 
> Why is the rps_intearctive flag needed in plane state? I wanted to 
> assume prepare & cleanup hooks are fully symmetric, but this flags makes 
> me unsure. A reviewer with more display knowledge will be needed here I 
> think.

It's so that when we call intel_cleanup_plane_fb() on something that
wasn't first prepared, we don't decrement the counter. There's a little
bit of asymmetry at the start where we inherit the plane state.

> > +
> >   /* Should only be called after a successful intel_prepare_plane_fb()! 
> > */
> >   mutex_lock(_priv->drm.struct_mutex);
> >   intel_plane_unpin_fb(to_intel_plane_state(old_state));
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 61e715ddd0d5..544812488821 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -482,6 +482,8 @@ struct intel_atomic_state {
> >*/
> >   bool skip_intermediate_wm;
> >   
> > + bool rps_interactive;
> 
> Should the name at this level be something more tied to the subsystem 
> and not implying wider relationships? Like page flip pending? fb_prepared?

But we are in the plane state so anything plane/flip is implied. I think
saying whether or not we've called out to rps is a reasonable name for
the state.

> > + /* Max/min bins are special */
> > + if (val <= rps->min_freq_softlimit)
> > + new_power = LOW_POWER;
> > + if (val >= rps->max_freq_softlimit)
> > + new_power = HIGH_POWER;
> > +
> > + mutex_lock(>power_lock);
> 
> Is it worth avoiding the atomic here when GEN < 6?

We don't get here when not !RPS. You mean GEN < 5 ;)

> > + if (rps->interactive)
> > + new_power = HIGH_POWER;
> > + rps_set_power(dev_priv, new_power);
> > + mutex_unlock(>power_lock);
>  >
>  >  rps->last_adj = 0;
> 
> This block should go up to the beginning of the function since when 
> rps->interactive all preceding calculations are for nothing. And can 
> immediately return then.

We have to lock around rps_set_power, so you're not going to avoid
taking the lock here, so I don't think it makes any difference.
Certainly neater than locking everything.

> > +void intel_rps_set_interactive(struct drm_i915_private *dev_priv, bool 
> > state)
> 
> s/state/interactive/ for more self-documenting function body?
> 
> And not s/dev_priv/i915/ ?!? :)
> 
> > +{
> > + struct intel_rps *rps = _priv->gt_pm.rps;
> > +
> > + if (INTEL_GEN(dev_priv) < 6)
> > + return;
> > +
> > + mutex_lock(>power_lock);
> > + if (state) {
> > + if (!rps->interactive++ && READ_ONCE(dev_priv->gt.awake))
> > + rps_set_power(dev_priv, HIGH_POWER);
> > + } else {
> > + GEM_BUG_ON(!rps->interactive);
> > + rps->interactive--;
> 
> Hm maybe protect this in production code so some missed code flows in 
> the atomic paths do not cause underflow and so permanent interactive mode.

Are you suggesting testing is inadequate? ;) Underflow here isn't a big
deal, it just locks in the HIGH_POWER (faster sampling, bias towards
upclocking). Or worse not allow HIGH_POWER, status quo returned.
-Chris
___

Re: [Intel-gfx] [PATCH 05/12] dmar: Use for_each_If

[Joerg Roedel]

On Mon, Jul 09, 2018 at 10:36:43AM +0200, Daniel Vetter wrote:
>  #define for_each_active_drhd_unit(drhd)  
> \
>   list_for_each_entry_rcu(drhd, _drhd_units, list)   \
> - if (drhd->ignored) {} else
> + for_each_if (!drhd->ignored)

Hmm, in my tree the macro comes from

include/drm/drmP.h:#define for_each_if(condition) if (!(condition)) {} 
else

Please re-submit when the macro is in a generic header upstream.


Joerg

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

Re: [Intel-gfx] [RESEND] drm/i915: Interactive RPS mode

[Tvrtko Ursulin]

On 12/07/2018 18:38, Chris Wilson wrote:

RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high load, and low despite occasional glitches under steady
low load, and inbetween. However, we run into situations like kodi where
we want to stay at low power (video decoding is done efficiently
inside the fixed function HW and doesn't need high clocks even for high
bitrate streams), but just occasionally the pipeline is more complex
than a video decode and we need a smidgen of extra GPU power to present
on time. In the high power regime, we sample at sub frame intervals with
a bias to upclocking, and conversely at low power we sample over a few
frames worth to provide what we consider to be the right levels of
responsiveness respectively. At low power, we more or less expect to be
kicked out to high power at the start of a busy sequence by waitboosting.

Prior to commit e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active
request") whenever we missed the frame or stalled, we would immediate go
full throttle and upclock the GPU to max. But in commit e9af4ea2b9e7, we
relaxed the waitboosting to only apply if the pipeline was deep to avoid
over-committing resources for a near miss. Sadly though, a near miss is
still a miss, and perceptible as jitter in the frame delivery.

To try and prevent the near miss before having to resort to boosting
after the fact, we use the pageflip queue as an indication that we are
in an "interactive" regime and so should sample the load more frequently
to provide power before the frame misses it vblank. This will make us
more favorable to providing a small power increase (one or two bins) as
required rather than going all the way to maximum and then having to
work back down again. (We still keep the waitboosting mechanism around
just in case a dramatic change in system load requires urgent uplocking,
faster than we can provide in a few evaluation intervals.)

v2: Reduce rps_set_interactive to a boolean parameter to avoid the
confusion of what if they wanted a new power mode after pinning to a
different mode (which to choose?)
v3: Only reprogram RPS while the GT is awake, it will be set when we
wake the GT, and while off warns about being used outside of rpm.
v4: Fix deferred application of interactive mode

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111
Fixes: e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Tvrtko Ursulin 
Cc: Radoslaw Szwichtenberg 
---
  drivers/gpu/drm/i915/i915_debugfs.c  |  1 +
  drivers/gpu/drm/i915/i915_drv.h  |  4 ++
  drivers/gpu/drm/i915/intel_display.c | 20 ++
  drivers/gpu/drm/i915/intel_drv.h |  2 +
  drivers/gpu/drm/i915/intel_pm.c  | 91 +++-
  5 files changed, 89 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 099f97ef2303..ac019bb927d0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2218,6 +2218,7 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
seq_printf(m, "CPU waiting? %d\n", count_irq_waiters(dev_priv));
seq_printf(m, "Boosts outstanding? %d\n",
   atomic_read(>num_waiters));
+   seq_printf(m, "Interactive? %d\n", READ_ONCE(rps->interactive));
seq_printf(m, "Frequency requested %d\n",
   intel_gpu_freq(dev_priv, rps->cur_freq));
seq_printf(m, "  min hard:%d, soft:%d; max soft:%d, hard:%d\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01dd29837233..f02fbeee553f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -784,6 +784,8 @@ struct intel_rps {
  
  	int last_adj;

enum { LOW_POWER, BETWEEN, HIGH_POWER } power;
+   unsigned int interactive;
+   struct mutex power_lock;
  
  	bool enabled;

atomic_t num_waiters;
@@ -3429,6 +3431,8 @@ extern void i915_redisable_vga_power_on(struct 
drm_i915_private *dev_priv);
  extern bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 val);
  extern void intel_init_pch_refclk(struct drm_i915_private *dev_priv);
  extern int intel_set_rps(struct drm_i915_private *dev_priv, u8 val);
+extern void intel_rps_set_interactive(struct drm_i915_private *dev_priv,
+ bool state);
  extern bool intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
  bool enable);
  
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c

index 7998e70a3174..5809366ff9f0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++