Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

On 2016.10.18 05:39:11 +, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
> > URL   : https://patchwork.freedesktop.org/series/13910/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
> > https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/
> > 
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > incomplete -> DMESG-WARN (fi-byt-n2820)
> Command   /opt/igt/tests/gem_exec_suspend --run-subtest basic-S3
> dmesg 
>  [  363.532729] Suspending console(s) (use no_console_suspend to debug)
> [  363.539402] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  363.540866] sd 0:0:0:0: [sda] Stopping disk
> [  364.370247] Broke affinity for irq 19
> [  364.370265] Broke affinity for irq 87
> [  364.370272] Broke affinity for irq 88
> [  364.370278] Broke affinity for irq 89
> [  364.388813]  cache: parent cpu1 should not be sleeping
> [  364.638398] [ cut here ]
> [  364.638409] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638412] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  364.638440] Modules linked in: snd_hda_intel i915 intel_powerclamp 
> coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel 
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec lpc_ich snd_hwdep 
> snd_hda_core snd_pcm i2c_designware_platform i2c_designware_core r8169 mii 
> sdhci_acpi sdhci i2c_hid mmc_core [last unloaded: i915]
> [  364.638444] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U  
> 4.9.0-rc1-CI-Patchwork_2740+ #1
> [  364.638446] Hardware name: 
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
>  
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
>  BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
> [  364.638453]  88013fd03d68 8142df05 88013fd03db8 
> 
> [  364.638458]  88013fd03da8 8107e496 0aa93fd03e08 
> 81e249a0
> [  364.638463]  8181d137 82e7e280  
> 0004
> [  364.638464] Call Trace:
> [  364.638472]   
> [  364.638473]  [] dump_stack+0x67/0x92
> [  364.638477]  [] __warn+0xc6/0xe0
> [  364.638483]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  364.638487]  [] warn_slowpath_fmt+0x4a/0x50
> [  364.638491]  [] ? rtc_handler+0x1d/0xa0
> [  364.638495]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638499]  [] trace_hardirqs_on+0xd/0x10
> [  364.638502]  [] _raw_spin_unlock_irq+0x27/0x50
> [  364.638505]  [] rtc_handler+0x32/0xa0
> [  364.638509]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  364.638513]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  364.638517]  [] acpi_irq+0x11/0x2c
> [  364.638521]  [] __handle_irq_event_percpu+0x58/0x370
> [  364.638525]  [] handle_irq_event_percpu+0x1e/0x50
> [  364.638528]  [] handle_irq_event+0x34/0x60
> [  364.638531]  [] handle_fasteoi_irq+0xa6/0x170
> [  364.638536]  [] handle_irq+0x15/0x20
> [  364.638539]  [] do_IRQ+0x68/0x130
> [  364.638542]  [] common_interrupt+0x89/0x89
> [  364.638548]   
> [  364.638548]  [] ? mwait_idle+0x93/0x210
> [  364.638551]  [] ? mwait_idle+0x8a/0x210
> [  364.638555]  [] arch_cpu_idle+0xa/0x10
> [  364.638558]  [] default_idle_call+0x1e/0x30
> [  364.638561]  [] cpu_startup_entry+0x17c/0x1f0
> [  364.638565]  [] start_secondary+0x102/0x120
> [  364.638568] ---[ end trace 302f2b5e754e367a ]---
> 
> > dmesg-warn -> INCOMPLETE (fi-byt-j1900)
> 
> [075/246] skip: 12, pass: 62, fail: 1 -
> running: igt/gem_exec_suspend/basic-s3 
> 
> [075/246] skip: 12, pass: 62, fail: 1 \
> Build timed out (after 18 minutes). Marking the build as aborted.
> 
> > Test vgem_basic:
> > Subgroup unload:
> > skip   -> PASS   (fi-hsw-4770r)
> > pass   -> SKIP   (fi-bdw-5557u)
> > 
> > fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> > fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42
> > fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> > fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12
> > fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35
> > fi-hsw-4770  total:246  pass:224  dwarn:0   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
> URL   : https://patchwork.freedesktop.org/series/13910/
> State : failure
> 
> == Summary ==
> 
> Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
> https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> incomplete -> DMESG-WARN (fi-byt-n2820)
Command /opt/igt/tests/gem_exec_suspend --run-subtest basic-S3
dmesg   
 [  363.532729] Suspending console(s) (use no_console_suspend to debug)
[  363.539402] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  363.540866] sd 0:0:0:0: [sda] Stopping disk
[  364.370247] Broke affinity for irq 19
[  364.370265] Broke affinity for irq 87
[  364.370272] Broke affinity for irq 88
[  364.370278] Broke affinity for irq 89
[  364.388813]  cache: parent cpu1 should not be sleeping
[  364.638398] [ cut here ]
[  364.638409] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2729 
trace_hardirqs_on_caller+0x113/0x1b0
[  364.638412] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[  364.638440] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp 
crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec lpc_ich snd_hwdep 
snd_hda_core snd_pcm i2c_designware_platform i2c_designware_core r8169 mii 
sdhci_acpi sdhci i2c_hid mmc_core [last unloaded: i915]
[  364.638444] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U  
4.9.0-rc1-CI-Patchwork_2740+ #1
[  364.638446] Hardware name: 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
 BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
[  364.638453]  88013fd03d68 8142df05 88013fd03db8 

[  364.638458]  88013fd03da8 8107e496 0aa93fd03e08 
81e249a0
[  364.638463]  8181d137 82e7e280  
0004
[  364.638464] Call Trace:
[  364.638472]   
[  364.638473]  [] dump_stack+0x67/0x92
[  364.638477]  [] __warn+0xc6/0xe0
[  364.638483]  [] ? _raw_spin_unlock_irq+0x27/0x50
[  364.638487]  [] warn_slowpath_fmt+0x4a/0x50
[  364.638491]  [] ? rtc_handler+0x1d/0xa0
[  364.638495]  [] trace_hardirqs_on_caller+0x113/0x1b0
[  364.638499]  [] trace_hardirqs_on+0xd/0x10
[  364.638502]  [] _raw_spin_unlock_irq+0x27/0x50
[  364.638505]  [] rtc_handler+0x32/0xa0
[  364.638509]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
[  364.638513]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
[  364.638517]  [] acpi_irq+0x11/0x2c
[  364.638521]  [] __handle_irq_event_percpu+0x58/0x370
[  364.638525]  [] handle_irq_event_percpu+0x1e/0x50
[  364.638528]  [] handle_irq_event+0x34/0x60
[  364.638531]  [] handle_fasteoi_irq+0xa6/0x170
[  364.638536]  [] handle_irq+0x15/0x20
[  364.638539]  [] do_IRQ+0x68/0x130
[  364.638542]  [] common_interrupt+0x89/0x89
[  364.638548]   
[  364.638548]  [] ? mwait_idle+0x93/0x210
[  364.638551]  [] ? mwait_idle+0x8a/0x210
[  364.638555]  [] arch_cpu_idle+0xa/0x10
[  364.638558]  [] default_idle_call+0x1e/0x30
[  364.638561]  [] cpu_startup_entry+0x17c/0x1f0
[  364.638565]  [] start_secondary+0x102/0x120
[  364.638568] ---[ end trace 302f2b5e754e367a ]---

> dmesg-warn -> INCOMPLETE (fi-byt-j1900)

[075/246] skip: 12, pass: 62, fail: 1 -
running: igt/gem_exec_suspend/basic-s3 

[075/246] skip: 12, pass: 62, fail: 1 \
Build timed out (after 18 minutes). Marking the build as aborted.

> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-hsw-4770r)
> pass   -> SKIP   (fi-bdw-5557u)
> 
> fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12
> fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0  

[Intel-gfx] [i-g-t PATCH] igt/tools: Update intel_watermark with SKL support

[Dhinakaran Pandiyan]

Added support to print SKL watermark and DDB registers.

Signed-off-by: Dhinakaran Pandiyan 
---
 tools/intel_watermark.c | 104 +++-
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
index e9a2b05..903a0b2 100644
--- a/tools/intel_watermark.c
+++ b/tools/intel_watermark.c
@@ -120,6 +120,11 @@ static const char *endis(bool enabled)
return enabled ? "enabled" : "disabled";
 }
 
+static const char endis_ast(bool enabled)
+{
+   return enabled ? '*' : ' ';
+}
+
 static int is_gen7_plus(uint32_t d)
 {
return !(IS_GEN5(d) || IS_GEN6(d));
@@ -130,6 +135,101 @@ static int is_hsw_plus(uint32_t d)
return !(IS_GEN5(d) || IS_GEN6(d) || IS_IVYBRIDGE(d));
 }
 
+
+static void skl_wm_dump(void)
+{
+   int pipe, plane, level;
+   int num_pipes = 3;
+   int num_planes = 5;
+   int num_levels = 8;
+   uint32_t base_addr = 0x7, addr, wm_offset;
+
+   uint32_t wm[num_levels][num_pipes][num_planes];
+   uint32_t wm_trans[num_pipes][num_planes];
+   uint32_t buf_cfg[num_pipes][num_planes];
+
+   intel_register_access_init(intel_get_pci_device(), 0);
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   for (plane = 0; plane < num_planes; plane++) {
+   addr =  base_addr +  pipe * 0x1000 + plane * 0x100;
+
+   wm_trans[pipe][plane] = read_reg(addr + 0x00168);
+   buf_cfg[pipe][plane] = read_reg(addr + 0x0017C);
+   for (level = 0; level < num_levels; level++) {
+   wm_offset = addr + 0x00140 + level * 0x4;
+   wm[level][pipe][plane] = read_reg(wm_offset);
+   }
+   }
+   }
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   uint32_t start, end, size;
+   uint32_t lines, blocks, enable;
+
+   printf("PIPE_%c\n", pipe_name(pipe));
+   printf("LEVEL   CURSOR   PLANE_A   PLANE_B   PLANE_C   
PLANE_D\n");
+   for (level = 0; level < num_levels; level++) {
+   printf("%5d  ", level);
+   for (plane = 0; plane < num_planes; plane++) {
+   blocks = REG_DECODE1(wm[level][pipe][plane], 0, 
9);
+   lines = REG_DECODE1(wm[level][pipe][plane], 14, 
5);
+   enable = REG_DECODE1(wm[level][pipe][plane], 
31, 1);
+
+   printf("%3d", blocks);
+   printf("%c", endis_ast(enable));
+   if (!REG_DECODE1(wm[level][pipe][plane], 30, 1))
+   printf("(%2d)  ", lines);
+   else
+   printf("(--)  ");
+   }
+   printf("\n");
+   }
+
+   printf("TRANS: ");
+   for (plane = 0; plane < num_planes; plane++) {
+   blocks = REG_DECODE1(wm_trans[pipe][plane], 0, 9);
+   lines = REG_DECODE1(wm_trans[pipe][plane], 14, 5);
+   enable = REG_DECODE1(wm_trans[pipe][plane], 31, 1);
+
+   printf("%3d", blocks);
+   printf("%c", endis_ast(enable));
+   if (!REG_DECODE1(wm_trans[pipe][plane], 30, 1))
+   printf("(%2d)  ", lines);
+   else
+   printf("(--)  ");
+   }
+
+   printf("\nDDB allocation:");
+
+   printf("\nstart ");
+   for (plane = 0; plane < num_planes; plane++) {
+   start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
+   printf("%7d   ", start);
+   }
+
+   printf("\nend   ");
+   for (plane = 0; plane < num_planes; plane++) {
+   end = REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
+   printf("%7d   ", end);
+   }
+
+   printf("\nsize  ");
+   for (plane = 0; plane < num_planes; plane++) {
+   start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
+   end =  REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
+   size = end - start + 1;
+   printf("%7d   ", (end == 0 && size == 1) ? 0 : size);
+   }
+
+   printf("\n\n\n");
+   }
+
+   printf("* plane watermark enabled\n");
+   printf("(x) line watermark if enabled\n");
+
+}
+
 static void ilk_wm_dump(void)
 {
int i;
@@ -900,7 +1000,9 @@ int main(int argc, char *argv[])
 {
devid = intel_get_pci_device()->device_id;
 
-   if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid)) {
+   

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
URL   : https://patchwork.freedesktop.org/series/13910/
State : failure

== Summary ==

Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-byt-n2820)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u failed to connect after reboot
fi-skl-6770hq failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2740/

7ec75289774dec48c46c37271fb334b7caed3d32 drm-intel-nightly: 
2016y-10m-17d-14h-07m-32s UTC integration manifest
ae305ca drm/i915/gvt: Fix build failure after intel_engine_cs change

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

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.17 16:07:50 +0200, Daniel Vetter wrote:
> Yeah might be best to have a new branch with upstreaming stuff (now you
> need to at least split out bugfixes for the already merged stuff) and
> treat that like a mostly stable branch. And the still unmerged features
> (vfio and all that) would then get rebased on top of that.
>

yeah, plan to do so, vfio part hasn't been merged, will rebase on new branch.

> 
> Also I already screwed up the merge, it doesn't even compile :( Sorry
> about that. Can you pls create a quick fixup patch just to make it work
> again and submit to intel-gfx? That way I can apply it directly.
> 

Done. As currently GVT-g code is closed bound to some i915 struct and
interface, any change for i915 interface might be possible to affect
GVT-g. As general rule API changer should cover for us too, but we might
try to capture that earlier, well at least 0day guy will shout out loudly.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


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

[Intel-gfx] [PATCH] drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

Change GVT-g code reference for intel_engine_cs from static array to
allocated pointer after commit 3b3f1650b1ca ("drm/i915: Allocate
intel_engine_cs structure only for the enabled engines").

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/execlist.c  | 2 +-
 drivers/gpu/drm/i915/gvt/handlers.c  | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index 4a00ee7..c50a3d1 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -39,7 +39,7 @@
 #define _EL_OFFSET_STATUS_PTR   0x3A0
 
 #define execlist_ring_mmio(gvt, ring_id, offset) \
-   (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
+   (gvt->dev_priv->engine[ring_id]->mmio_base + (offset))
 
 #define valid_context(ctx) ((ctx)->valid)
 #define same_context(a, b) (((a)->context_id == (b)->context_id) && \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index d59a934..e8ec403 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -134,7 +134,7 @@ static int render_mmio_to_ring_id(struct intel_gvt *gvt, 
unsigned int reg)
 
reg &= ~GENMASK(11, 0);
for (i = 0; i < I915_NUM_ENGINES; i++) {
-   if (gvt->dev_priv->engine[i].mmio_base == reg)
+   if (gvt->dev_priv->engine[i]->mmio_base == reg)
return i;
}
return -1;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 732672b..b15cdf5 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -68,7 +68,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   >dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -171,7 +171,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
 
-   workload->req = i915_gem_request_alloc(_priv->engine[ring_id],
+   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
   shadow_ctx);
if (IS_ERR_OR_NULL(workload->req)) {
gvt_err("fail to allocate gem request\n");
@@ -298,7 +298,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   >dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

[Manasi Navare]

On Thu, Oct 06, 2016 at 10:54:01AM -0700, Rodrigo Vivi wrote:
> According to spec: "KBL re-uses SKL values, except where
> specific KBL values are listed."
> 
> And recently spec has changed adding different table for Display Port only.
> But for all SKUs (H,S,U,Y) we have slightly different values.
> 
> v2: Fix wrong condition spotted by Jani.
> 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 88 
> +++-
>  1 file changed, 78 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 35f0b7c..195aa70 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -167,8 +167,47 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_dp[] = {
>   { 0x80005012, 0x00C0, 0x3 },
>  };
>  
> +/* Kabylake H and S */
> +static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
> + { 0x2016, 0x00A0, 0x0 },
> + { 0x5012, 0x009B, 0x0 },
> + { 0x7011, 0x0088, 0x0 },
> + { 0x80009010, 0x00C0, 0x1 },
> + { 0x2016, 0x009B, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00C0, 0x1 },
> + { 0x2016, 0x009F, 0x0 },

This entry according to the Bspec should be 0x2016, 0x0097, 0x0

Manasi


> + { 0x80005012, 0x00C0, 0x1 },
> +};
> +
> +/* Kabylake U */
> +static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
> + { 0x201B, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x80009010, 0x00C0, 0x3 },
> + { 0x201B, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x2016, 0x004F, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
> +/* Kabylake Y */
> +static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
> + { 0x1017, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x8000800F, 0x00C0, 0x3 },
> + { 0x1017, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x1017, 0x004C, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
>  /*
> - * Skylake H and S
> + * Skylake/Kabylake H and S
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> @@ -185,7 +224,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake U
> + * Skylake/Kabylake U
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
> @@ -202,7 +241,7 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake Y
> + * Skylake/Kabylake Y
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
> @@ -218,7 +257,7 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_edp[] = {
>   { 0x0018, 0x008A, 0x0 },
>  };
>  
> -/* Skylake U, H and S */
> +/* Skylake/Kabylake U, H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00AC, 0x0 },
>   { 0x5012, 0x009D, 0x0 },
> @@ -233,7 +272,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_hdmi[] = {
>   { 0x8018, 0x00C0, 0x1 },
>  };
>  
> -/* Skylake Y */
> +/* Skylake/Kabylake Y */
>  static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00A1, 0x0 },
>   { 0x5012, 0x00DF, 0x0 },
> @@ -334,10 +373,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private 
> *dev_priv, int *n_entries)
>  static const struct ddi_buf_trans *
>  skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> - if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
> + if (IS_SKL_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
>   return skl_y_ddi_translations_dp;
> - } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
> + } else if (IS_SKL_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
>   return skl_u_ddi_translations_dp;
>   } else {
> @@ -347,6 +386,21 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>  }
>  
>  static const struct ddi_buf_trans *
> +kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +{
> + if (IS_KBL_ULX(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
> + return kbl_y_ddi_translations_dp;
> + } else if 

[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

j->base));
  ^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
drivers/gpu/drm/i915/gvt/execlist.c:42:33: error: request for member 
'mmio_base' in something not a structure or union
  (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
 ^
drivers/gpu/drm/i915/gvt/execlist.c:248:19: note: in expansi
on of macro 'execlist_ring_mmio'
  u32 status_reg = execlist_ring_mmio(vgpu->gvt, ring_id,
   ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_sh
adow_batch_buffer':
drivers/gpu/drm/i915/gvt/execlist.c:501:4: warning: 'drm_gem
_object_unreference' is deprecated [-Wdeprecated-declarations]
drm_gem_object_unreference(&(entry_obj->obj->base));
^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35
:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_sh
adow_wa_ctx':
drivers/gpu/drm/i915/gvt/execlist.c:514:2: warning: 
'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
  drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
  ^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
drivers/gpu/drm/i915/gvt/execlist.c:42:33: error: request for member 
'mmio_base' in something not a structure or union
  (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
 ^
drivers/gpu/drm/i915/gvt/execlist.c:798:23: note: in expansion of macro 
'execlist_ring_mmio'
  ctx_status_ptr_reg = execlist_ring_mmio(vgpu->gvt, ring_id,
   ^

Caused by commit

  3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines")

interacting with some other commits that were merged without fixes being 
applied (probably) in commit

  06a75ace46e2 ("Merge tag 'gvt-next-2016-10-14' of 
https://github.com/01org/gvt-linux into drm-intel-next-queued")

I have used the version of the drm-intel tree from next-20161017 for
today.

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

[Intel-gfx] [drm-intel:for-linux-next 0/3] drivers/gpu/drm/i915/gvt/handlers.c:137: error: request for member 'mmio_base' in something not a structure or union

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   bfd02b3c557caa083be0d55a3164ede706a446e1
commit: 06a75ace46e2fdd1d93b06228df0e2dfe526cc27 [0/3] Merge tag 
'gvt-next-2016-10-14' of https://github.com/01org/gvt-linux into 
drm-intel-next-queued
config: x86_64-randconfig-s0-10180350 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 06a75ace46e2fdd1d93b06228df0e2dfe526cc27
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/gvt/handlers.c: In function 'render_mmio_to_ring_id':
>> drivers/gpu/drm/i915/gvt/handlers.c:137: error: request for member 
>> 'mmio_base' in something not a structure or union
--
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'emulate_execlist_status':
>> drivers/gpu/drm/i915/gvt/execlist.c:97: error: request for member 
>> 'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'emulate_csb_update':
   drivers/gpu/drm/i915/gvt/execlist.c:136: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c:138: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'get_next_execlist_slot':
   drivers/gpu/drm/i915/gvt/execlist.c:248: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
   drivers/gpu/drm/i915/gvt/execlist.c:798: error: request for member 
'mmio_base' in something not a structure or union
--
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'populate_shadow_context':
>> drivers/gpu/drm/i915/gvt/scheduler.c:71: warning: passing argument 1 of 
>> 'intel_lr_context_size' from incompatible pointer type
   drivers/gpu/drm/i915/intel_lrc.h:84: note: expected 'struct intel_engine_cs 
*' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'dispatch_workload':
>> drivers/gpu/drm/i915/gvt/scheduler.c:175: warning: passing argument 1 of 
>> 'i915_gem_request_alloc' from incompatible pointer type
   drivers/gpu/drm/i915/i915_gem_request.h:156: note: expected 'struct 
intel_engine_cs *' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'update_guest_context':
   drivers/gpu/drm/i915/gvt/scheduler.c:301: warning: passing argument 1 of 
'intel_lr_context_size' from incompatible pointer type
   drivers/gpu/drm/i915/intel_lrc.h:84: note: expected 'struct intel_engine_cs 
*' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.o: warning: objtool: 
complete_current_workload()+0x771: function has unreachable instruction

vim +/mmio_base +137 drivers/gpu/drm/i915/gvt/handlers.c

28c4c6ca Zhi Wang 2016-05-01  131  static int render_mmio_to_ring_id(struct 
intel_gvt *gvt, unsigned int reg)
28c4c6ca Zhi Wang 2016-05-01  132  {
28c4c6ca Zhi Wang 2016-05-01  133   int i;
28c4c6ca Zhi Wang 2016-05-01  134  
28c4c6ca Zhi Wang 2016-05-01  135   reg &= ~GENMASK(11, 0);
28c4c6ca Zhi Wang 2016-05-01  136   for (i = 0; i < I915_NUM_ENGINES; i++) {
28c4c6ca Zhi Wang 2016-05-01 @137   if 
(gvt->dev_priv->engine[i].mmio_base == reg)
28c4c6ca Zhi Wang 2016-05-01  138   return i;
28c4c6ca Zhi Wang 2016-05-01  139   }
28c4c6ca Zhi Wang 2016-05-01  140   return -1;

:: The code at line 137 was first introduced by commit
:: 28c4c6ca7f794b2d5ac8773d43311e95f6518415 drm/i915/gvt: vGPU workload 
submission

:: TO: Zhi Wang 
:: CC: Zhenyu Wang 

---
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 12/15] drm: RIP mode_config->rotation_property

[Laurent Pinchart]

Hi Ville,

On Friday 22 Jul 2016 16:43:13 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that all drivers have been converted over to the per-plane rotation
> property, we can just nuke the global rotation property.
> 
> Signed-off-by: Ville Syrjälä 

Stupid question, but how does this work when the hardware supports global 
rotation only, not per-plane rotation ?

> ---
>  drivers/gpu/drm/drm_atomic.c|  6 ++
>  drivers/gpu/drm/drm_crtc.c  | 18 --
>  drivers/gpu/drm/drm_fb_helper.c |  7 +--
>  include/drm/drm_crtc.h  |  7 ---
>  4 files changed, 3 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 116f940a9267..81061fcdb984 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -709,8 +709,7 @@ int drm_atomic_plane_set_property(struct drm_plane
> *plane, state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_ROTATE_MASK))
>   return -EINVAL;
>   state->rotation = val;
> @@ -768,8 +767,7 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
property, val);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9e20a52ece7c..c1df75caf72f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5783,24 +5783,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
> 
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device
> *dev, -  unsigned int 
supported_rotations)
> -{
> - static const struct drm_prop_enum_list props[] = {
> - { DRM_ROTATE_0,   "rotate-0" },
> - { DRM_ROTATE_90,  "rotate-90" },
> - { DRM_ROTATE_180, "rotate-180" },
> - { DRM_ROTATE_270, "rotate-270" },
> - { DRM_REFLECT_X,  "reflect-x" },
> - { DRM_REFLECT_Y,  "reflect-y" },
> - };
> -
> - return drm_property_create_bitmask(dev, 0, "rotation",
> -props, ARRAY_SIZE(props),
> -supported_rotations);
> -}
> -EXPORT_SYMBOL(drm_mode_create_rotation_property);
> -
>  int drm_plane_create_rotation_property(struct drm_plane *plane,
>  unsigned int rotation,
>  unsigned int supported_rotations)
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c index ce536c0553e5..cf5f071ffae1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -392,15 +392,10 @@ static int restore_fbdev_mode(struct drm_fb_helper
> *fb_helper) if (plane->type != DRM_PLANE_TYPE_PRIMARY)
>   drm_plane_force_disable(plane);
> 
> - if (plane->rotation_property) {
> + if (plane->rotation_property)
>   drm_mode_plane_set_obj_prop(plane,
>   plane->rotation_property,
>   BIT(DRM_ROTATE_0));
> - } else if (dev->mode_config.rotation_property) {
> - drm_mode_plane_set_obj_prop(plane,
> - dev-
>mode_config.rotation_property,
> - BIT(DRM_ROTATE_0));
> - }
>   }
> 
>   for (i = 0; i < fb_helper->crtc_count; i++) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 01cf0673f6c8..00a93e44f854 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2480,11 +2480,6 @@ struct drm_mode_config {
>*/
>   struct drm_property *plane_type_property;
>   /**
> -  * @rotation_property: Optional property for planes or CRTCs to 
specify
> -  * rotation.
> -  */
> - struct drm_property *rotation_property;
> - /**
>* @prop_src_x: Default atomic plane property for the plane source
>* position in the connected _framebuffer.
>*/
> @@ -2960,8 +2955,6 @@ 

[Intel-gfx] [PATCH xf86-video-intel] sna: Reprobe if kernel updates the connector mode list

[Manasi Navare]

Output_check_status() should return a false if it detects
that the connector mode list has changed so that sna_mode_discover
can reprobe.

Fixes: eb01cc549d4d (sna: Refresh mode list if the kernel updates)

Signed-off-by: Manasi Navare 
Cc: Chris Wilson 
Cc: Ville Syrjala 
---
 src/sna/sna_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 15be27c..ea7e287 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -5191,7 +5191,7 @@ output_check_status(struct sna *sna, struct sna_output 
*output)
return true;
 
if (output->num_modes != compat_conn.conn.count_modes)
-   return true;
+   return false;
 
if (output->edid_len == 0)
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] [PATCH 1/2] drm/i915/gen9: fix watermarks when using the pipe scaler

[Matt Roper]

On Fri, Oct 07, 2016 at 05:28:57PM -0300, Paulo Zanoni wrote:
> Luckily, the necessary adjustments for when we're using the scaler are
> exactly the same as the ones needed on ILK+, so just reuse the
> function we already have.
> 
> v2: Invert the patch order so stable backports get easier.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni 

I thought there was a patch floating around to fix this back before I
went on break a couple months ago, but I can't find it now, so this
looks good.

For both patches:

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fe6c1c6..000b033 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3470,12 +3470,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   return 0;
>  }
>  
> -static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state *config)
> -{
> - /* TODO: Take into account the scalers once we support them */
> - return config->base.adjusted_mode.crtc_clock;
> -}
> -
>  /*
>   * The max latency should be 257 (max the punit can code is 255 and we add 
> 2us
>   * for the read latency) and cpp should always be <= 8, so that
> @@ -3526,7 +3520,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
> struct intel_crtc_state *cst
>* Adjusted plane pixel rate is just the pipe's adjusted pixel rate
>* with additional adjustments for plane-specific scaling.
>*/
> - adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
> + adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
>   downscale_amount = skl_plane_downscale_amount(pstate);
>  
>   pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
> @@ -3742,11 +3736,11 @@ skl_compute_linetime_wm(struct intel_crtc_state 
> *cstate)
>   if (!cstate->base.active)
>   return 0;
>  
> - if (WARN_ON(skl_pipe_pixel_rate(cstate) == 0))
> + if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
>   return 0;
>  
>   return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
> - skl_pipe_pixel_rate(cstate));
> + ilk_pipe_pixel_rate(cstate));
>  }
>  
>  static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Trust VBT aux/ddc information (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Trust VBT aux/ddc information (rev2)
URL   : https://patchwork.freedesktop.org/series/13600/
State : failure

== Summary ==

Series 13600v2 drm/i915: Trust VBT aux/ddc information
https://patchwork.freedesktop.org/api/1.0/series/13600/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-byt-n2820)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test pm_backlight:
Subgroup basic-brightness:
skip   -> PASS   (fi-skl-6700k)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-bdw-5557u)
skip   -> PASS   (fi-hsw-4770r)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:222  dwarn:1   dfail:0   fail:0   skip:23 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-ivb-3520m failed to connect after reboot
fi-skl-6260u failed to connect after reboot
fi-skl-6770hq failed to connect after reboot
fi-snb-2520m failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2739/

7ec75289774dec48c46c37271fb334b7caed3d32 drm-intel-nightly: 
2016y-10m-17d-14h-07m-32s UTC integration manifest
13ae602 drm/i915: Fix whitespace issues
ebded98 drm/i915: Clean up DDI DDC/AUX CH sanitation
6ea77f6 drm/i915: Respect alternate_ddc_pin for all DDI ports
49a7f8a drm/i915: Respect alternate_aux_channel for all DDI ports

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

[Intel-gfx] [PATCH v3 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[ville . syrjala]

From: Ville Syrjälä 

Now that we use the AUX and GMBUS assignment from VBT for all ports,
let's clean up the sanitization of the port information a bit.
Previosuly we only did this for port E, and only complained about a
non-standard assignment for the other ports. But as we know that
non-standard assignments are a fact of life, let's expand the
sanitization to all the ports.

v2: Include a commit message, fix up the comments a bit
v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
pin

Cc: sta...@vger.kernel.org
Cc: Maarten Maathuis 
Tested-by: Maarten Maathuis 
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
Reviewed-by: Jim Bride  (v2)
---
 drivers/gpu/drm/i915/intel_bios.c | 122 --
 1 file changed, 77 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8cdd6b..a8ff8c099685 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1035,6 +1035,77 @@ static u8 translate_iboost(u8 val)
return mapping[val];
 }
 
+static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
+enum port port)
+{
+   const struct ddi_vbt_port_info *info =
+   _priv->vbt.ddi_port_info[port];
+   enum port p;
+
+   if (!info->alternate_ddc_pin)
+   return;
+
+   for_each_port_masked(p, (1 << port) - 1) {
+   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
+
+   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
+   continue;
+
+   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as 
port %c, "
+ "disabling port %c DVI/HDMI support\n",
+ port_name(p), i->alternate_ddc_pin,
+ port_name(port), port_name(p));
+
+   /*
+* If we have multiple ports supposedly sharing the
+* pin, then dvi/hdmi couldn't exist on the shared
+* port. Otherwise they share the same ddc bin and
+* system couldn't communicate with them separately.
+*
+* Due to parsing the ports in alphabetical order,
+* a higher port will always clobber a lower one.
+*/
+   i->supports_dvi = false;
+   i->supports_hdmi = false;
+   i->alternate_ddc_pin = 0;
+   }
+}
+
+static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   const struct ddi_vbt_port_info *info =
+   _priv->vbt.ddi_port_info[port];
+   enum port p;
+
+   if (!info->alternate_aux_channel)
+   return;
+
+   for_each_port_masked(p, (1 << port) - 1) {
+   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
+
+   if (info->alternate_aux_channel != i->alternate_aux_channel)
+   continue;
+
+   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as 
port %c, "
+ "disabling port %c DP support\n",
+ port_name(p), i->alternate_aux_channel,
+ port_name(port), port_name(p));
+
+   /*
+* If we have multiple ports supposedlt sharing the
+* aux channel, then DP couldn't exist on the shared
+* port. Otherwise they share the same aux channel
+* and system couldn't communicate with them separately.
+*
+* Due to parsing the ports in alphabetical order,
+* a higher port will always clobber a lower one.
+*/
+   i->supports_dp = false;
+   i->alternate_aux_channel = 0;
+   }
+}
+
 static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
   const struct bdb_header *bdb)
 {
@@ -1109,54 +1180,15 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
 
if (is_dvi) {
-   if (port == PORT_E) {
-   info->alternate_ddc_pin = ddc_pin;
-   /* if DDIE share ddc pin with other port, then
-* dvi/hdmi couldn't exist on the shared port.
-* Otherwise they share the same ddc bin and system
-* couldn't communicate with them seperately. */
-   if (ddc_pin == DDC_PIN_B) 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Ville Syrjälä]

On Tue, Oct 11, 2016 at 08:52:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
> 
> v2: Include a commit message, fix up the comments a bit
> 
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 116 
> +++---
>  1 file changed, 71 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8cdd6b..6d1ffa815e97 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1035,6 +1035,71 @@ static u8 translate_iboost(u8 val)
>   return mapping[val];
>  }
>  
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +

Hmm. And I just realized this code is probably slightly garbage. If the
current port doesn't have alternate_ddc_pin/alternate_aux_channel, then
we'd proceed to clobber any lower port without the thing as well. Now,
potentially all DDI platforms have this stuff fully decked out in VBT so
it might not matter in practice. But better safe that sorry, so I'll
send out a new version of this patch that checks here for the zero
case in both of these functions.

> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as 
> port %c, "
> +   "disabling port %c DVI/HDMI support\n",
> +   port_name(p), i->alternate_ddc_pin,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedly sharing the
> +  * pin, then dvi/hdmi couldn't exist on the shared
> +  * port. Otherwise they share the same ddc bin and
> +  * system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dvi = false;
> + i->supports_hdmi = false;
> + i->alternate_ddc_pin = 0;
> + }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +
> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_aux_channel != i->alternate_aux_channel)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as 
> port %c, "
> +   "disabling port %c DP support\n",
> +   port_name(p), i->alternate_aux_channel,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedlt sharing the
> +  * aux channel, then DP couldn't exist on the shared
> +  * port. Otherwise they share the same aux channel
> +  * and system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dp = false;
> + i->alternate_aux_channel = 0;
> + }
> +}
> +
>  static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
>  const struct bdb_header *bdb)
>  {
> @@ -1109,54 +1174,15 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv, enum port port,
>   DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
>  
>   if (is_dvi) {
> - if (port == PORT_E) {
> - info->alternate_ddc_pin = ddc_pin;
> - /* if DDIE share ddc pin with other port, then
> -  

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Restrict pagefault disabling to just around copy_from_user()

[Patchwork]

== Series Details ==

Series: drm/i915: Restrict pagefault disabling to just around copy_from_user()
URL   : https://patchwork.freedesktop.org/series/13880/
State : failure

== Summary ==

Series 13880v1 drm/i915: Restrict pagefault disabling to just around 
copy_from_user()
https://patchwork.freedesktop.org/api/1.0/series/13880/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-byt-n2820)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test kms_force_connector_basic:
Subgroup force-load-detect:
incomplete -> PASS   (fi-ivb-3520m)
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-snb-2600)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-bdw-5557u)
skip   -> PASS   (fi-hsw-4770r)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:0   dfail:0   fail:5   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:186  pass:164  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2600  total:209  pass:176  dwarn:0   dfail:0   fail:0   skip:32 
fi-kbl-7200u failed to collect. IGT log at Patchwork_2738/fi-kbl-7200u/igt.log
fi-skl-6260u failed to connect after reboot
fi-skl-6770hq failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2738/

7ec75289774dec48c46c37271fb334b7caed3d32 drm-intel-nightly: 
2016y-10m-17d-14h-07m-32s UTC integration manifest
bde1775 drm/i915: Restrict pagefault disabling to just around copy_from_user()

___
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/DMC/KBL: Load DMC on KBL using he no_stepping_info array

[Vivi, Rodrigo]

On Fri, 2016-10-14 at 16:56 -0700, Anusha Srivatsa wrote:
> Currently, for display there is only one DMC image for KBL.
> Remove the stepping_info table for KBL and use the no_stepping_info
> for loading the firmware image.
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index cf57167..e0e348b 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -168,12 +168,6 @@ struct stepping_info {
>   char substepping;
>  };
>  
> -static const struct stepping_info kbl_stepping_info[] = {
> - {'A', '0'}, {'B', '0'}, {'C', '0'},
> - {'D', '0'}, {'E', '0'}, {'F', '0'},
> - {'G', '0'}, {'H', '0'}, {'I', '0'},
> -};
> -
>  static const struct stepping_info skl_stepping_info[] = {
>   {'A', '0'}, {'B', '0'}, {'C', '0'},
>   {'D', '0'}, {'E', '0'}, {'F', '0'},
> @@ -197,8 +191,8 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
>   unsigned int size;
>  
>   if (IS_KABYLAKE(dev_priv)) {
> - size = ARRAY_SIZE(kbl_stepping_info);
> - si = kbl_stepping_info;
> + size = ARRAY_SIZE(no_stepping_info);
> + si = no_stepping_info;

I believe we could just remove this entire block so it would just return
the no_stepping_info...


>   } else if (IS_SKYLAKE(dev_priv)) {
>   size = ARRAY_SIZE(skl_stepping_info);
>   si = skl_stepping_info;

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmc: Make no_stepping_info an array

[Vivi, Rodrigo]

Reviewed-by: Rodrigo Vivi 

On Fri, 2016-10-14 at 16:56 -0700, Anusha Srivatsa wrote:
> Make no_stepping_info an array of structs so that
> on plaforms that have only one binary of DMC, we can
> iterate through this array by having the same logic
> for firmware loads
> 
> Cc: Rodrigo Vivi 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 1ea0e1f..cf57167 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -186,7 +186,9 @@ static const struct stepping_info bxt_stepping_info[] = {
>   {'B', '0'}, {'B', '1'}, {'B', '2'}
>  };
>  
> -static const struct stepping_info no_stepping_info = { '*', '*' };
> +static const struct stepping_info no_stepping_info[] = {
> + { '*', '*' }
> +};
>  
>  static const struct stepping_info *
>  intel_get_stepping_info(struct drm_i915_private *dev_priv)
> @@ -210,7 +212,7 @@ intel_get_stepping_info(struct drm_i915_private *dev_priv)
>   if (INTEL_REVID(dev_priv) < size)
>   return si + INTEL_REVID(dev_priv);
>  
> - return _stepping_info;
> + return no_stepping_info;
>  }
>  
>  static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)

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

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 8:30 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 08:21:21PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 10/17/2016 7:36 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 10/17/2016 6:01 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too
V3: Rebase
V4: Added r-b from Jose
---
drivers/gpu/drm/drm_modes.c | 31 +++
1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;

+	/* Clearing picture aspect ratio bits from out flags */

+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.

In drm layer, this is the only place. Actually till now, DRM layer dint
have the support for aspect ratio at all. This was causing
HDMI compliance tests like 7-27 fail, which expect a particular unique
VIC in AVI infoframe on modeset.

I have given some details about this in cover-letter.

Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.

I had a small discussion on this with Daniel, and we discussed that it
doesnt make sense to override just the aspect ratio if the monitor
doesn't even support that aspect ratio.
And currently the was how this property is implemented is, we just
override the aspect ratio without any validity check.

Now as we have all the supported aspect ratio added properly in the mode
info itself, we need not to have this property at all, So Daniel
suggested me to remove that property too.

And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915.

Yes, This is a bug in I915. When I published the first version of this
series, I had one patch, 

Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Imre Deak]

On ma, 2016-10-17 at 18:01 +0300, Saarinen, Jani wrote:
> HI, 
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On
> > Behalf
> > Of Imre Deak
> > Sent: Monday, October 17, 2016 5:47 PM
> > To: Daniel Vetter 
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] intel-ci: Add
> > gem_exec_suspend/basic-
> > S3/S4-devices to BAT
> > 
> > On ma, 2016-10-17 at 16:32 +0200, Daniel Vetter wrote:
> > > On Mon, Oct 17, 2016 at 03:39:04PM +0300, Imre Deak wrote:
> > > > Add gem_exec_suspend/basic-s3-devices and basic-s4-devices
> > > > subtests
> > > > to BAT. At the same time remove basic-s4 from the list, which
> > > > is atm
> > > > implicitly disabled via HIBERNATION=n in kconfig. We would need
> > > > at
> > > > least basic S4 coverage provided by basic-s4-devices, which
> > > > requires
> > > > HIBERNATION=y.
> > > > 
> > > > Signed-off-by: Imre Deak 
> > > 
> > > What's the impact on BAT runtime with this?
> Are these also stable enough to be added so that we are not causing
> flip-flops?

Based on my tests, they are.

> > I measured 8 sec for S3-devices and 9 sec for S4-devices on my APL.
> > 
> > > Afaik we're already over budget ... Where do you safe the time to
> > > afford this?
> > 
> > I didn't, but we don't have any S4 coverage in CI atm and it's the
> > minimum
> > that can be added. The S3-devices subtest is not critical, although
> > it would be
> > useful for cases where we wouldn't get any logs for the full S3
> > test.
> > 
> > --Imre
> > 
> > > -Daniel
> > > 
> > > > ---
> > > >  tests/intel-ci/fast-feedback.testlist | 3 ++-
> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/tests/intel-ci/fast-feedback.testlist
> > > > b/tests/intel-
> > > > ci/fast-feedback.testlist index f59ec98..efa7e86 100644
> > > > --- a/tests/intel-ci/fast-feedback.testlist
> > > > +++ b/tests/intel-ci/fast-feedback.testlist
> > > > @@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
> > > >  igt@gem_exec_store@basic-render
> > > >  igt@gem_exec_store@basic-vebox
> > > >  igt@gem_exec_suspend@basic
> > > > +igt@gem_exec_suspend@basic-s3-devices
> > > >  igt@gem_exec_suspend@basic-s3
> > > > -igt@gem_exec_suspend@basic-s4
> > > > +igt@gem_exec_suspend@basic-s4-devices
> > > >  igt@gem_flink_basic@bad-flink
> > > >  igt@gem_flink_basic@bad-open
> > > >  igt@gem_flink_basic@basic
> > > > --
> > > > 2.5.0
> > > > 
> 
> Jani Saarinen
> Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
> 
> 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Saarinen, Jani]

HI, 
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Imre Deak
> Sent: Monday, October 17, 2016 5:47 PM
> To: Daniel Vetter 
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-
> S3/S4-devices to BAT
> 
> On ma, 2016-10-17 at 16:32 +0200, Daniel Vetter wrote:
> > On Mon, Oct 17, 2016 at 03:39:04PM +0300, Imre Deak wrote:
> > > Add gem_exec_suspend/basic-s3-devices and basic-s4-devices subtests
> > > to BAT. At the same time remove basic-s4 from the list, which is atm
> > > implicitly disabled via HIBERNATION=n in kconfig. We would need at
> > > least basic S4 coverage provided by basic-s4-devices, which requires
> > > HIBERNATION=y.
> > >
> > > Signed-off-by: Imre Deak 
> >
> > What's the impact on BAT runtime with this?
Are these also stable enough to be added so that we are not causing flip-flops?

> 
> I measured 8 sec for S3-devices and 9 sec for S4-devices on my APL.
> 
> > Afaik we're already over budget ... Where do you safe the time to
> > afford this?
> 
> I didn't, but we don't have any S4 coverage in CI atm and it's the minimum
> that can be added. The S3-devices subtest is not critical, although it would 
> be
> useful for cases where we wouldn't get any logs for the full S3 test.
> 
> --Imre
> 
> > -Daniel
> >
> > > ---
> > >  tests/intel-ci/fast-feedback.testlist | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-
> > > ci/fast-feedback.testlist index f59ec98..efa7e86 100644
> > > --- a/tests/intel-ci/fast-feedback.testlist
> > > +++ b/tests/intel-ci/fast-feedback.testlist
> > > @@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
> > >  igt@gem_exec_store@basic-render
> > >  igt@gem_exec_store@basic-vebox
> > >  igt@gem_exec_suspend@basic
> > > +igt@gem_exec_suspend@basic-s3-devices
> > >  igt@gem_exec_suspend@basic-s3
> > > -igt@gem_exec_suspend@basic-s4
> > > +igt@gem_exec_suspend@basic-s4-devices
> > >  igt@gem_flink_basic@bad-flink
> > >  igt@gem_flink_basic@bad-open
> > >  igt@gem_flink_basic@basic
> > > --
> > > 2.5.0
> > >

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 08:21:21PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 10/17/2016 7:36 PM, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> >>> On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
>  Current DRM layer functions don't parse aspect ratio information
>  while converting a user mode->kernel mode or vice versa. This
>  causes modeset to pick mode with wrong aspect ratio, eventually
>  causing failures in HDMI compliance test cases, due to wrong VIC.
> 
>  This patch adds aspect ratio information in DRM's mode conversion
>  and mode comparision functions, to make sure kernel picks mode
>  with right aspect ratio (as per the VIC).
> 
>  Signed-off-by: Shashank Sharma 
>  Signed-off-by: Lin, Jia 
>  Signed-off-by: Akashdeep Sharma 
>  Reviewed-by: Jim Bride 
>  Reviewed-by: Jose Abreu 
>  Cc: Daniel Vetter 
>  Cc: Emil Velikov 
> 
>  V2: Addressed review comments from Sean:
>  - Fix spellings/typo
>  - No need to handle aspect ratio none
>  - Add a break, for default case too
>  V3: Rebase
>  V4: Added r-b from Jose
>  ---
> drivers/gpu/drm/drm_modes.c | 31 +++
> 1 file changed, 31 insertions(+)
> 
>  diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>  index 53f07ac..fde927a 100644
>  --- a/drivers/gpu/drm/drm_modes.c
>  +++ b/drivers/gpu/drm/drm_modes.c
>  @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
>  drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
>  +mode1->picture_aspect_ratio == mode2->picture_aspect_ratio 
>  &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>    (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
>  @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
>  drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
>  +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>  +
>  +switch (in->picture_aspect_ratio) {
>  +case HDMI_PICTURE_ASPECT_4_3:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
>  +break;
>  +case HDMI_PICTURE_ASPECT_16_9:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
>  +break;
>  +case HDMI_PICTURE_ASPECT_RESERVED:
>  +default:
>  +out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
>  +break;
>  +}
>  +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> }
>  @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct 
>  drm_display_mode *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> 
>  +/* Clearing picture aspect ratio bits from out flags */
>  +out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
>  +
>  +switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
>  +case DRM_MODE_FLAG_PIC_AR_4_3:
>  +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
>  +break;
>  +case DRM_MODE_FLAG_PIC_AR_16_9:
>  +out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
>  +break;
>  +default:
>  +out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
>  +break;
>  +}
> >>> Hmm. So now we have the mode aspect ratio infromation duplicated
> >>> in two different places. Not sure that won't lead to some confusion.
> >> In drm layer, this is the only place. Actually till now, DRM layer dint
> >> have the support for aspect ratio at all. This was causing
> >> HDMI compliance tests like 7-27 fail, which expect a particular unique
> >> VIC in AVI infoframe on modeset.
> >>
> >> I have given some details about this in cover-letter.
> >>> Although we do want the user to be able to override via the property I
> >>> suppose, so we'd have to change that (+ the inforframe code) to
> >>> look at the mode flags instead if we would eliminate
> >>> 'picture_aspect_ratio'.
> >> I had a small discussion on this with Daniel, and we discussed that it
> >> 

Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Jani Nikula]

On Mon, 17 Oct 2016, Imre Deak  wrote:
> On ma, 2016-10-17 at 16:32 +0200, Daniel Vetter wrote:
>> On Mon, Oct 17, 2016 at 03:39:04PM +0300, Imre Deak wrote:
>> > Add gem_exec_suspend/basic-s3-devices and basic-s4-devices subtests
>> > to
>> > BAT. At the same time remove basic-s4 from the list, which is atm
>> > implicitly disabled via HIBERNATION=n in kconfig. We would need at
>> > least
>> > basic S4 coverage provided by basic-s4-devices, which requires
>> > HIBERNATION=y.
>> > 
>> > Signed-off-by: Imre Deak 
>> 
>> What's the impact on BAT runtime with this? 
>
> I measured 8 sec for S3-devices and 9 sec for S4-devices on my APL.
>
>> Afaik we're already over budget ... Where do you safe the time to
>> afford this?
>
> I didn't, but we don't have any S4 coverage in CI atm and it's the
> minimum that can be added. The S3-devices subtest is not critical,
> although it would be useful for cases where we wouldn't get any logs
> for the full S3 test.

If our CI was sufficiently clever, it could detect these patches to
change the test list, and let us all know what the impact is...

BR,
Jani.



>
> --Imre
>
>> -Daniel
>> 
>> > ---
>> >  tests/intel-ci/fast-feedback.testlist | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > 
>> > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-
>> > ci/fast-feedback.testlist
>> > index f59ec98..efa7e86 100644
>> > --- a/tests/intel-ci/fast-feedback.testlist
>> > +++ b/tests/intel-ci/fast-feedback.testlist
>> > @@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
>> >  igt@gem_exec_store@basic-render
>> >  igt@gem_exec_store@basic-vebox
>> >  igt@gem_exec_suspend@basic
>> > +igt@gem_exec_suspend@basic-s3-devices
>> >  igt@gem_exec_suspend@basic-s3
>> > -igt@gem_exec_suspend@basic-s4
>> > +igt@gem_exec_suspend@basic-s4-devices
>> >  igt@gem_flink_basic@bad-flink
>> >  igt@gem_flink_basic@bad-open
>> >  igt@gem_flink_basic@basic
>> > -- 
>> > 2.5.0
>> > 
>> > ___
>> > 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

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

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 7:36 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 10/17/2016 6:01 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too
V3: Rebase
V4: Added r-b from Jose
---
   drivers/gpu/drm/drm_modes.c | 31 +++
   1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
   }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
   
+	/* Clearing picture aspect ratio bits from out flags */

+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.

In drm layer, this is the only place. Actually till now, DRM layer dint
have the support for aspect ratio at all. This was causing
HDMI compliance tests like 7-27 fail, which expect a particular unique
VIC in AVI infoframe on modeset.

I have given some details about this in cover-letter.

Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.

I had a small discussion on this with Daniel, and we discussed that it
doesnt make sense to override just the aspect ratio if the monitor
doesn't even support that aspect ratio.
And currently the was how this property is implemented is, we just
override the aspect ratio without any validity check.

Now as we have all the supported aspect ratio added properly in the mode
info itself, we need not to have this property at all, So Daniel
suggested me to remove that property too.

And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915.

Yes, This is a bug in I915. When I published the first version of this
series, I had one patch, which was overriding the value only when the
property is set.
This should be the right case. And then Daniel suggested to remove the

Re: [Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Imre Deak]

On ma, 2016-10-17 at 16:32 +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 03:39:04PM +0300, Imre Deak wrote:
> > Add gem_exec_suspend/basic-s3-devices and basic-s4-devices subtests
> > to
> > BAT. At the same time remove basic-s4 from the list, which is atm
> > implicitly disabled via HIBERNATION=n in kconfig. We would need at
> > least
> > basic S4 coverage provided by basic-s4-devices, which requires
> > HIBERNATION=y.
> > 
> > Signed-off-by: Imre Deak 
> 
> What's the impact on BAT runtime with this? 

I measured 8 sec for S3-devices and 9 sec for S4-devices on my APL.

> Afaik we're already over budget ... Where do you safe the time to
> afford this?

I didn't, but we don't have any S4 coverage in CI atm and it's the
minimum that can be added. The S3-devices subtest is not critical,
although it would be useful for cases where we wouldn't get any logs
for the full S3 test.

--Imre

> -Daniel
> 
> > ---
> >  tests/intel-ci/fast-feedback.testlist | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-
> > ci/fast-feedback.testlist
> > index f59ec98..efa7e86 100644
> > --- a/tests/intel-ci/fast-feedback.testlist
> > +++ b/tests/intel-ci/fast-feedback.testlist
> > @@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
> >  igt@gem_exec_store@basic-render
> >  igt@gem_exec_store@basic-vebox
> >  igt@gem_exec_suspend@basic
> > +igt@gem_exec_suspend@basic-s3-devices
> >  igt@gem_exec_suspend@basic-s3
> > -igt@gem_exec_suspend@basic-s4
> > +igt@gem_exec_suspend@basic-s4-devices
> >  igt@gem_flink_basic@bad-flink
> >  igt@gem_flink_basic@bad-open
> >  igt@gem_flink_basic@basic
> > -- 
> > 2.5.0
> > 
> > ___
> > 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] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Daniel Vetter]

On Mon, Oct 17, 2016 at 03:39:04PM +0300, Imre Deak wrote:
> Add gem_exec_suspend/basic-s3-devices and basic-s4-devices subtests to
> BAT. At the same time remove basic-s4 from the list, which is atm
> implicitly disabled via HIBERNATION=n in kconfig. We would need at least
> basic S4 coverage provided by basic-s4-devices, which requires
> HIBERNATION=y.
> 
> Signed-off-by: Imre Deak 

What's the impact on BAT runtime with this? Afaik we're already over
budget ... Where do you safe the time to afford this?
-Daniel

> ---
>  tests/intel-ci/fast-feedback.testlist | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/tests/intel-ci/fast-feedback.testlist 
> b/tests/intel-ci/fast-feedback.testlist
> index f59ec98..efa7e86 100644
> --- a/tests/intel-ci/fast-feedback.testlist
> +++ b/tests/intel-ci/fast-feedback.testlist
> @@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
>  igt@gem_exec_store@basic-render
>  igt@gem_exec_store@basic-vebox
>  igt@gem_exec_suspend@basic
> +igt@gem_exec_suspend@basic-s3-devices
>  igt@gem_exec_suspend@basic-s3
> -igt@gem_exec_suspend@basic-s4
> +igt@gem_exec_suspend@basic-s4-devices
>  igt@gem_flink_basic@bad-flink
>  igt@gem_flink_basic@bad-open
>  igt@gem_flink_basic@basic
> -- 
> 2.5.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

[Daniel Vetter]

On Mon, Oct 17, 2016 at 02:28:37PM +0300, Mika Kahola wrote:
> + for (int i = 0; i < iterations; i++) {
> + igt_info("%d/%d: Testing connector %s using pipe %s with %d 
> planes\n",
> +  i+1, iterations, igt_output_name(output),
> +  kmstest_pipe_name(pipe), max_planes);
> +
> + test_init(data, pipe);
> +
> + test_grab_crc(data, output, pipe, , tiling,
> +   _crc);
> +
> + test_planes(data, pipe, , tiling, max_planes, output);
> +
> + if (test_atomic) {
> + igt_display_commit_atomic(>display,
> +   DRM_MODE_PAGE_FLIP_EVENT,
> +   >display);
> + } else
> + igt_display_commit2(>display, COMMIT_LEGACY);
> +
> + igt_pipe_crc_start(data->pipe_crc);
> + n = igt_pipe_crc_get_crcs(data->pipe_crc, 1, );
> + igt_assert_eq(n, 1);
> + igt_pipe_crc_stop(data->pipe_crc);

Comment on testing method here: With atomic we don't just require that the
result looks good at the end, but also that _every_ frame is perfect. That
means you need a slightly different test sequence:

1. Enable crc capture.

2. Create a new atomic state (randomized, whatever) which should in the
end still result in the same screen contents using the punchout box trick.
This depends upon the exact subtest.

3. Commit the state from step 2.

4. Wait to make sure the atomic commit has completed. If you do an async
commit, that means waiting for the flip_event to get signalled (didn't see
code for that anywhere).

5. Fetch all the crc values (if there's not a bug in your code or in the
kernel it should be just 1) and make sure they are _all_ the right value.
Your code here only grabs 1 crc after the atomic commit completed, which
means if there's tearing or underruns you'll miss them. Which means it
won't actually validate the crucial feature for which we've created
atomic!

6. Go back to 2.

7. After enough loops, stop crc capturing.

Note that this is the loop for ALLOW_MODESET==false atomic commits, i.e.
where every atomic commit should take at most 1 vblank interval. If any of
the commits take longer than that, there's a bug in either the kernel or
your testcase. Note that crc_start alone has a few vblank waits (due to
crc bugs on some platforms) which will break this.

Cheers, Daniel

> +
> + igt_assert_crc_equal(_crc, crc);
> +
> + test_fini(data, output, max_planes);
> + }
> +}
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

[Joonas Lahtinen]

On ma, 2016-10-17 at 16:10 +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 03:33:43PM +0300, Joonas Lahtinen wrote:
> > Maybe we could even explicitly state that bugs should be reported to
> > the distro bugzilla because of running an old kernel?
> 
> Distro's already shut down our warnings "because too much noise", I don't
> think that's valuable.

Reviewed-by: Joonas Lahtinen 

Just needs a patch to DIM to bump the timestamp.

Regards, Joonas

> 
> > Acked-by: Daniel Vetter 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH igt] lib/igt_aux: Improve documentation for igt_system_suspend_autoresume()

[Daniel Vetter]

On Fri, Oct 14, 2016 at 05:51:14PM +0300, Imre Deak wrote:
> While at it fix the order of states for consistency.
> 
> Suggested by Daniel.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Imre Deak 

Going ocd with docs makes me really happy \o/ And I think it does help
for new folks to get started in our dragon dungeon of a driver. Thanks for 
doing this.

Reviewed-by: Daniel Vetter 

> ---
>  lib/igt_aux.c | 21 -
>  lib/igt_aux.h | 36 +++-
>  2 files changed, 51 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> index f225c2f..421f6d4 100644
> --- a/lib/igt_aux.c
> +++ b/lib/igt_aux.c
> @@ -628,8 +628,8 @@ void igt_cleanup_aperture_trashers(void)
>  
>  static const char *suspend_state_name[] = {
>   [SUSPEND_STATE_FREEZE] = "freeze",
> - [SUSPEND_STATE_MEM] = "mem",
>   [SUSPEND_STATE_STANDBY] = "standby",
> + [SUSPEND_STATE_MEM] = "mem",
>   [SUSPEND_STATE_DISK] = "disk",
>  };
>  
> @@ -744,11 +744,22 @@ static uint32_t get_supported_suspend_states(int 
> power_dir)
>  
>  /**
>   * igt_system_suspend_autoresume:
> + * @state: an #igt_suspend_state, the target suspend state
> + * @test: an #igt_suspend_test, test point at which to complete the suspend
> + * cycle
>   *
> - * Execute a system suspend (to idle, memory, disk) cycle optionally
> - * completing the cycle at a given test point and automaically wake up again.
> - * Waking up is either achieved using the RTC wake-up alarm for a full 
> suspend
> - * cycle or a kernel timer for a suspend test cycle.
> + * Execute a system suspend cycle targeting the given @state optionally
> + * completing the cycle at the given @test point and automaically wake up
> + * again. Waking up is either achieved using the RTC wake-up alarm for a full
> + * suspend cycle or a kernel timer for a suspend test cycle. The kernel timer
> + * delay for a test cycle can be configured by the suspend.pm_test_delay
> + * kernel parameter (5 sec by default).
> + *
> + * #SUSPEND_TEST_NONE specifies a full suspend cycle.
> + * The #SUSPEND_TEST_FREEZER..#SUSPEND_TEST_CORE test points can make it
> + * possible to collect error logs in case a full suspend cycle would prevent
> + * this by hanging the machine, or they can provide an idea of the faulty
> + * component by comparing fail/no-fail results at different test points.
>   *
>   * This is very handy for implementing any kind of suspend/resume test.
>   */
> diff --git a/lib/igt_aux.h b/lib/igt_aux.h
> index 39fd8ea..d30196b 100644
> --- a/lib/igt_aux.h
> +++ b/lib/igt_aux.h
> @@ -116,15 +116,48 @@ void igt_cleanup_aperture_trashers(void);
>  
>  /* suspend/hibernate and auto-resume system */
>  
> +/**
> + *  igt_suspend_state:
> + *  @SUSPEND_STATE_FREEZE: suspend-to-idle target state, aka S0ix or freeze,
> + *  first non-hibernation state
> + *  @SUSPEND_STATE_STANDBY: standby target state, aka S1, second
> + *   non-hibernation state
> + *  @SUSPEND_STATE_MEM: suspend-to-mem target state aka S3, third
> + *   non-hibernation state
> + *  @SUSPEND_STATE_DISK: suspend-to-disk target state, aka S4 or hibernation
> + *
> + *  Target suspend states used with igt_system_suspend_autoresume().
> + *  See /sys/power/state for the available states on a given machine.
> + */
>  enum igt_suspend_state {
>   SUSPEND_STATE_FREEZE,
> - SUSPEND_STATE_MEM,
>   SUSPEND_STATE_STANDBY,
> + SUSPEND_STATE_MEM,
>   SUSPEND_STATE_DISK,
>  
> + /*< private >*/
>   SUSPEND_STATE_NUM,
>  };
>  
> +/**
> + * igt_suspend_test:
> + * @SUSPEND_TEST_NONE: no testing, perform a full suspend/resume cycle
> + * @SUSPEND_TEST_FREEZER: complete cycle after freezing all freezable threads
> + * @SUSPEND_TEST_DEVICES: complete cycle after the above step and suspending
> + * devices (before calling the drivers' suspend late and
> + * no_irq hooks). Platform and system devices are not
> + * suspended here, see #SUSPEND_TEST_CORE.
> + * @SUSPEND_TEST_PLATFORM: complete cycle after all the above steps and 
> calling
> + *  the ACPI platform global control methods (applies
> + *  only with /sys/power/disk set to platform)
> + * @SUSPEND_TEST_PROCESSORS: complete cycle after all the above steps and
> + *disabling non-boot CPUs
> + * @SUSPEND_TEST_CORE: complete cycle after all the above steps and 
> suspending
> + *  platform and system devices
> + *
> + * Test points used with igt_system_suspend_autoresume(). Specifies if and 
> where
> + * the suspend sequence is to be terminated.
> + */
>  enum igt_suspend_test {
>   SUSPEND_TEST_NONE,
>   SUSPEND_TEST_FREEZER,
> @@ -133,6 +166,7 @@ enum igt_suspend_test {
>   SUSPEND_TEST_PROCESSORS,
>   SUSPEND_TEST_CORE,
>  
> 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: GMBUS don't need no forcewake

[Ville Syrjälä]

On Wed, Oct 12, 2016 at 01:49:20PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: GMBUS don't need no forcewake
> URL   : https://patchwork.freedesktop.org/series/13641/
> State : warning
> 
> == Summary ==
> 
> Series 13641v1 drm/i915: GMBUS don't need no forcewake
> https://patchwork.freedesktop.org/api/1.0/series/13641/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> DMESG-WARN (fi-ilk-650)

[   44.582062] [drm:intel_enable_pipe [i915]] enabling pipe B
[   44.582480] [drm:ironlake_fdi_link_train [i915]] FDI_RX_IIR 0x100
[   44.582505] [drm:ironlake_fdi_link_train [i915]] FDI train 1 done.
[   44.582684] [drm:ironlake_fdi_link_train [i915]] FDI_RX_IIR 0x600
[   44.582708] [drm:ironlake_fdi_link_train [i915]] FDI train 2 done.
[   44.582732] [drm:ironlake_fdi_link_train [i915]] FDI train done
[   44.582758] [drm:intel_enable_shared_dpll [i915]] enable PCH DPLL B (active 
2, on? 0) for crtc 30
[   44.582781] [drm:intel_enable_shared_dpll [i915]] enabling PCH DPLL B
[   44.584207] [drm:intel_dp_program_link_training_pattern [i915]] Using DP 
training pattern TPS1
[   44.585526] [drm:intel_dp_set_signal_levels [i915]] Using signal levels 

[   44.585551] [drm:intel_dp_set_signal_levels [i915]] Using vswing level 0
[   44.585574] [drm:intel_dp_set_signal_levels [i915]] Using pre-emphasis level 0
[   44.585599] [drm:intel_dp_program_link_training_pattern [i915]] Using DP 
training pattern TPS1
[   44.586310] [drm:intel_dp_start_link_train [i915]] clock recovery OK
[   44.586344] [drm:intel_dp_program_link_training_pattern [i915]] Using DP 
training pattern TPS2
[   44.587380] [drm:intel_dp_start_link_train [i915]] Channel EQ done. DP 
Training successful
[   44.587587] [drm:intel_enable_dp [i915]] Enabling DP audio on pipe B
[   44.587614] [drm:intel_audio_codec_enable [i915]] ELD on 
[CONNECTOR:40:DP-1], [ENCODER:39:DP C]
[   44.587639] [drm:ilk_audio_codec_enable [i915]] Enable audio codec on port 
C, pipe B, 36 bytes ELD
[   44.604682] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH 
transcoder B FIFO underrun

so this is the non-link retraining case, which could be audio related
(or not).

https://bugs.freedesktop.org/show_bug.cgi?id=98251

Patch pushe to dinq, thanks for the review.

> Test kms_pipe_crc_basic:
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-byt-j1900)
> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-hsw-4770)
> 
> fi-bdw-5557u total:248  pass:232  dwarn:0   dfail:0   fail:0   skip:16 
> fi-bsw-n3050 total:248  pass:205  dwarn:0   dfail:0   fail:0   skip:43 
> fi-bxt-t5700 total:248  pass:217  dwarn:0   dfail:0   fail:0   skip:31 
> fi-byt-j1900 total:248  pass:214  dwarn:1   dfail:0   fail:1   skip:32 
> fi-byt-n2820 total:248  pass:211  dwarn:0   dfail:0   fail:1   skip:36 
> fi-hsw-4770  total:248  pass:225  dwarn:0   dfail:0   fail:0   skip:23 
> fi-hsw-4770r total:248  pass:225  dwarn:0   dfail:0   fail:0   skip:23 
> fi-ilk-650   total:248  pass:184  dwarn:1   dfail:0   fail:2   skip:61 
> fi-ivb-3520m total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
> fi-ivb-3770  total:248  pass:222  dwarn:0   dfail:0   fail:0   skip:26 
> fi-kbl-7200u total:248  pass:223  dwarn:0   dfail:0   fail:0   skip:25 
> fi-skl-6260u total:248  pass:233  dwarn:0   dfail:0   fail:0   skip:15 
> fi-skl-6700hqtotal:248  pass:225  dwarn:0   dfail:0   fail:0   skip:23 
> fi-skl-6700k total:248  pass:222  dwarn:1   dfail:0   fail:0   skip:25 
> fi-skl-6770hqtotal:248  pass:231  dwarn:1   dfail:0   fail:1   skip:15 
> fi-snb-2520m total:248  pass:211  dwarn:0   dfail:0   fail:0   skip:37 
> fi-snb-2600  total:248  pass:210  dwarn:0   dfail:0   fail:0   skip:38 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2685/
> 
> 46271d41e30090d7fc996e8f5abde6a59f51038b drm-intel-nightly: 
> 2016y-10m-12d-11h-06m-41s UTC integration manifest
> 3d9fd0b drm/i915: GMBUS don't need no forcewake

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

[Intel-gfx] [PATCH] drm/i915: Restrict pagefault disabling to just around copy_from_user()

[Chris Wilson]

When handling execbuf relocations, we play a delicate dance with
pagefault. We first try to access the user pages underneath our
struct_mutex. However, if those pages were inside a GEM object, we may
trigger a pagefault and deadlock as i915_gem_fault() tries to
recursively acquire struct_mutex. Instead, we choose to disable
pagefaulting around the copy_from_user whilst inside the struct_mutex
and handle the EFAULT by falling back to a copy outside the
struct_mutex.

We however presumed that disabling pagefaults would be expensive. It is
just an operation on the local current task. Cheap enough that we can
restrict the disable/enable to the critical section around the copy, and
so avoid having to handle the atomic sections within the relocation
handling itself.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 64 +-
 1 file changed, 28 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 1d02e74ce62d..22342ad0e07f 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -551,20 +551,6 @@ repeat:
return 0;
 }
 
-static bool object_is_idle(struct drm_i915_gem_object *obj)
-{
-   unsigned long active = i915_gem_object_get_active(obj);
-   int idx;
-
-   for_each_active(active, idx) {
-   if (!i915_gem_active_is_idle(>last_read[idx],
->base.dev->struct_mutex))
-   return false;
-   }
-
-   return true;
-}
-
 static int
 i915_gem_execbuffer_relocate_entry(struct drm_i915_gem_object *obj,
   struct eb_vmas *eb,
@@ -648,10 +634,6 @@ i915_gem_execbuffer_relocate_entry(struct 
drm_i915_gem_object *obj,
return -EINVAL;
}
 
-   /* We can't wait for rendering with pagefaults disabled */
-   if (pagefault_disabled() && !object_is_idle(obj))
-   return -EFAULT;
-
ret = relocate_entry(obj, reloc, cache, target_offset);
if (ret)
return ret;
@@ -678,12 +660,23 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
remain = entry->relocation_count;
while (remain) {
struct drm_i915_gem_relocation_entry *r = stack_reloc;
-   int count = remain;
-   if (count > ARRAY_SIZE(stack_reloc))
-   count = ARRAY_SIZE(stack_reloc);
+   unsigned long unwritten;
+   unsigned int count;
+
+   count = min_t(unsigned int, remain, ARRAY_SIZE(stack_reloc));
remain -= count;
 
-   if (__copy_from_user_inatomic(r, user_relocs, 
count*sizeof(r[0]))) {
+   /* This is the fast path and we cannot handle a pagefault
+* whilst holding the struct mutex lest the user pass in the
+* relocations contained within a mmaped bo. For in such a case
+* we, the page fault handler would call i915_gem_fault() and
+* we would try to acquire the struct mutex again. Obviously
+* this is bad and so lockdep complains vehemently.
+*/
+   pagefault_disable();
+   unwritten = __copy_from_user_inatomic(r, user_relocs, 
count*sizeof(r[0]));
+   pagefault_enable();
+   if (unwritten) {
ret = -EFAULT;
goto out;
}
@@ -695,11 +688,19 @@ i915_gem_execbuffer_relocate_vma(struct i915_vma *vma,
if (ret)
goto out;
 
-   if (r->presumed_offset != offset &&
-   __put_user(r->presumed_offset,
-  _relocs->presumed_offset)) {
-   ret = -EFAULT;
-   goto out;
+   if (r->presumed_offset != offset) {
+   /* Copying back to the user is allowed to fail.
+* The information passed back is a hint as
+* to the final location. If the copy_to_user
+* fails after a successful copy_from_user,
+* it must be a readonly location and so
+* we presume the user knows what they are
+* doing!
+*/
+   pagefault_disable();
+   __put_user(r->presumed_offset,
+  _relocs->presumed_offset);
+   pagefault_enable();
}
 
  

Re: [Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

[Daniel Vetter]

On Mon, Oct 17, 2016 at 03:33:43PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-14 at 14:44 +0100, Chris Wilson wrote:
> > If the kernel is old, more than a few releases old, chances are that the
> > user is using an old kernel for a good reason, despite there being GPU
> > hangs. After 180days since driver release stop suggesting that they
> > should send those reports upstream.
> > 
> > Signed-off-by: Chris Wilson 
> > Cc: Daniel Vetter 
> 
> Maybe we could even explicitly state that bugs should be reported to
> the distro bugzilla because of running an old kernel?

Distro's already shut down our warnings "because too much noise", I don't
think that's valuable.

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

Re: [Intel-gfx] [PATCH 0/2] drm/i915: Suppress underrun reporting around DP link retraining

[Ville Syrjälä]

On Fri, Oct 14, 2016 at 08:02:52PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> This series should reduce the underrn spam in CI. I expect it won't eliminate 
> it entirely
> as we seem to have two classes of dmesg warns: from link retraining, and from 
> normal
> modesets. The second category will need more investigation, but one suspect 
> might be
> the audio enable sequence.
> 
> Ville Syrjälä (2):
>   drm/i915: Extract intel_crtc_pch_transcoder()
>   drm/i915: Suppress underruns during DP link retraining

Series merge to dinq. Thanks for the reviews.

> 
>  drivers/gpu/drm/i915/intel_display.c | 21 ++---
>  drivers/gpu/drm/i915/intel_dp.c  | 29 +++--
>  drivers/gpu/drm/i915/intel_drv.h |  1 +
>  3 files changed, 42 insertions(+), 9 deletions(-)
> 
> -- 
> 2.7.4

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

Re: [Intel-gfx] [PATCH 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Chris Wilson]

On Mon, Oct 17, 2016 at 02:51:01PM +0100, Tvrtko Ursulin wrote:
> 
> On 17/10/2016 12:31, Chris Wilson wrote:
> >On Mon, Oct 17, 2016 at 11:55:54AM +0100, Tvrtko Ursulin wrote:
> >>On 14/10/2016 13:18, Chris Wilson wrote:
> >>>  static void
> >>>-i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
> >>>+i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj,
> >>>+struct sg_table *pages)
> >>>  {
> >>>   struct sgt_iter sgt_iter;
> >>>   struct page *page;
> >>>-  int ret;
> >>>-  GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
> >>>-
> >>>-  ret = i915_gem_object_set_to_cpu_domain(obj, true);
> >>>-  if (WARN_ON(ret)) {
> >>>-  /* In the event of a disaster, abandon all caches and
> >>>-   * hope for the best.
> >>>-   */
> >>>-  i915_gem_clflush_object(obj, true);
> >>>-  obj->base.read_domains = obj->base.write_domain = 
> >>>I915_GEM_DOMAIN_CPU;
> >>>-  }
> >>>+  __i915_gem_object_release_shmem(obj);
> >>Waiting for the object to become inactive is now gone. It did not
> >>spot that that changed with this patch. Did it?
> >There's no wait here. We have BUG_ONs today (that remain in place)
> >to catch trying to free pages that are in use by the GPU. This is just a
> >change of domains (and I wanted to keep the set-to-cpu-domain asserts,
> >and avoid the other side effects).
> 
> Oh right, makes sense.
> 
> >>>  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> >>>  {
> >>>-  struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> >>>-  const struct drm_i915_gem_object_ops *ops = obj->ops;
> >>>-  int ret;
> >>>+  int err;
> >>>   lockdep_assert_held(>base.dev->struct_mutex);
> >>>   if (obj->mm.pages)
> >>>   return 0;
> >>>-  if (obj->mm.madv != I915_MADV_WILLNEED) {
> >>>-  DRM_DEBUG("Attempting to obtain a purgeable object\n");
> >>>-  __i915_gem_object_unpin_pages(obj);
> >>>-  return -EFAULT;
> >>>-  }
> >>>-
> >>>-  ret = ops->get_pages(obj);
> >>>-  if (ret) {
> >>>+  err = i915_gem_object_get_pages(obj);
> >>>+  if (err)
> >>>   __i915_gem_object_unpin_pages(obj);
> >>>-  return ret;
> >>>-  }
> >>>-  list_add_tail(>global_list, _priv->mm.unbound_list);
> >>Objects will no longer appear on the unbound list when they have
> >>backing store?
> >They still do. We don't hold the struct_mutex here, so we defer the
> >global list tracking to the domain management which is slightly later.
> 
> Later as when VMA gets pinned?...

On unbind, and whilst unbound upon use by the user. 
 
> >However, there is still a window of opportunity where we have pages
> >pinned for our use but not yet visible to the shrinker. A bit of
> >rejigging should be mean we only need to move the unbound upon
> >pages_pin_count==0 and it will require a spinlock, but that make
> >actually work out to be less code. But it won't yet reduce the
> >struct_mutex hold time in the shrinker, so I'm not seeing the upside
> >yet.
> 
> ... in which case userspace just creating objects and not touching
> them avoids putting them on bound/unbound lists?

We don't allocate pages until the user uses them and that goes through
the domain tracking (should). Yes, there is a gap there and to solve that
we need to manage the mm.unbound_list using a spinlock rather than a mutex.
Just trying to decide if it is worth closing the hole now, or later when
we have a better idea of how to remove struct_mutex from the shrinker.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] GVT-g device model core

[Daniel Vetter]

On Mon, Oct 17, 2016 at 03:45:47PM +0800, Zhenyu Wang wrote:
> On 2016.10.17 09:33:19 +0200, Daniel Vetter wrote:
> > On Mon, Oct 17, 2016 at 09:30:45AM +0200, Daniel Vetter wrote:
> > > On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > This is first pull request to merge GVT-g device model in i915
> > > > which contains core GVT-g device model work to virtualize GPU
> > > > resources. This tries to add feature of Intel GVT-g technology
> > > > for full GPU virtualization. This version will support KVM based
> > > > virtualization solution named as KVMGT.
> > > > 
> > > > More background is on official project home: https://01.org/igvt-g
> > > > 
> > > > To manage mediated device between virtual GPU and physical device it
> > > > will rely on VFIO/mdev framework, this version has not included GVT-g
> > > > device model integration work for VFIO/mdev yet as VFIO community is
> > > > still under work to refine code base. Currently we're basing on
> > > > VFIO/mdev v8 patch series 
> > > > (http://www.spinics.net/lists/kvm/msg138515.html)
> > > > and doing more testings on that.
> > > > 
> > > > There're also several KVM change dependences. KVM maintainer has
> > > > merged two and we will ensure left hits KVM tree before sending new
> > > > pull request to enable that.
> > > > 
> > > > p.s, There would require some coordinate work for VFIO/mdev. We will
> > > > send device model work for that after Alex merged mdev framework in
> > > > VFIO tree. Alex has promised to merge that in early of Nov.
> > > > 
> > > > Let me know if there's any issue with this our first pull request.
> > > 
> > > Ok applied, but a few things to keep in mind before your next pull
> > > request:
> > > 
> > > - Dont rebase everything 5 seconds before sending out the pull request.
> > >   That just invalidates all the testing you've done, so not a good idea.
> > >   In general try to avoid rebases as much as possible, and only rebase to
> > >   take out a truly embarassing mistake. And then only rebase up to the
> > >   patch that needs a hotfix, not your entire tree.
> > > 
> > > - Similar, don't base your pull requests upon a random commit of the day
> > >   (that's why I noticed you rebased). Instead pick something meaningful,
> > >   like a tag I (or Dave Airlie or Linus Torvalds) push out. Or another
> > >   good option is to base it right on top of the last merge commit from
> > >   gvt. Once you've picked a baseline, don't change it (except when you
> > >   have a good reason). And if you need a patch from upstream also don't
> > >   rebase, just send out a pull request with your current patch pile, and
> > >   then continue applying more stuff on top once I merged that.
> > >
> 
> Sorry for that although we liked to include only core GVT-g device
> model in first pull request, we do have continual testing internally
> to cover GVT-g features. Will do as you said.

Yeah might be best to have a new branch with upstreaming stuff (now you
need to at least split out bugfixes for the already merged stuff) and
treat that like a mostly stable branch. And the still unmerged features
(vfio and all that) would then get rebased on top of that.

> > > - One technical nit on the integration: My idea was that i915 core code
> > >   only calls a few specific functions and structures exposed through
> > >   intel_gvt.h. But that file now seems to include gvt-internal headers,
> > >   which is a bit a mess. Please clean that up in the next pull request:
> > > 
> > >   * Anything that core i915 code or headers needs must be moved into
> > > intel_gvt.h.
> > >   * Everything else, including the 2 gvt includes we now have (gvt/gvt.h
> > > and i915_pvinfo.h) should only be included from code in
> > > drm/i915/gvt.h. So either sprinkle include directives over your source
> > > files for everything, or make gvt/gvt.h the main gvt header that pulls
> > > in everything.
> > > 
> > >   The idea here is similar to drm core vs. i915: drm core headers never
> > >   pull in i915 headers, and all communication happens through the
> > >   well-defined interfaces in drm core header files. I think our goal with
> > >   gvt should be similar, with all the interfaces being in intel_gvt.h.
> > >   Otherwise I fear the submaintainer model will be a bit painful, if we
> > >   don't aim for strict separation here.
> > >
> 
> yeah, that's a little messy, we will try to clean it up.
> 
> > > - There's not yet a MAINTAINERS entry for i915/gvt with gvt mailing lists,
> > >   git repos and your name on it. Please fix that in the next pull request,
> > >   too.
> 
> Will add that.
> 
> > > 
> > > - gvt seems to lack kernel-doc entirely. I think we need at least an
> > >   overview file and interface documentation for the stuff in
> > >   intel_gvt.[hc]. Please run
> > > 
> > >   $ make hmtldocs
> > > 
> > >   to make sure it all looks pretty (you need to add stanzas in
> > >   Documenation/gpu/i915.rst to 

Re: [Intel-gfx] [PULL] GVT-g device model core

[Jani Nikula]

On Mon, 17 Oct 2016, Daniel Vetter  wrote:
> Ok applied, but a few things to keep in mind before your next pull
> request:
>
> - Dont rebase everything 5 seconds before sending out the pull request.
>   That just invalidates all the testing you've done, so not a good idea.
>   In general try to avoid rebases as much as possible, and only rebase to
>   take out a truly embarassing mistake. And then only rebase up to the
>   patch that needs a hotfix, not your entire tree.

CONFIG_DRM_I915_GVT=y

drivers/gpu/drm/i915/gvt/handlers.c: In function ‘render_mmio_to_ring_id’:
drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: request for member 
‘mmio_base’ in something not a structure or union
   if (gvt->dev_priv->engine[i].mmio_base == reg)

BR,
Jani.


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

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 07:10:42PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 10/17/2016 6:01 PM, Ville Syrjälä wrote:
> > On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> >> Current DRM layer functions don't parse aspect ratio information
> >> while converting a user mode->kernel mode or vice versa. This
> >> causes modeset to pick mode with wrong aspect ratio, eventually
> >> causing failures in HDMI compliance test cases, due to wrong VIC.
> >>
> >> This patch adds aspect ratio information in DRM's mode conversion
> >> and mode comparision functions, to make sure kernel picks mode
> >> with right aspect ratio (as per the VIC).
> >>
> >> Signed-off-by: Shashank Sharma 
> >> Signed-off-by: Lin, Jia 
> >> Signed-off-by: Akashdeep Sharma 
> >> Reviewed-by: Jim Bride 
> >> Reviewed-by: Jose Abreu 
> >> Cc: Daniel Vetter 
> >> Cc: Emil Velikov 
> >>
> >> V2: Addressed review comments from Sean:
> >> - Fix spellings/typo
> >> - No need to handle aspect ratio none
> >> - Add a break, for default case too
> >> V3: Rebase
> >> V4: Added r-b from Jose
> >> ---
> >>   drivers/gpu/drm/drm_modes.c | 31 +++
> >>   1 file changed, 31 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> >> index 53f07ac..fde927a 100644
> >> --- a/drivers/gpu/drm/drm_modes.c
> >> +++ b/drivers/gpu/drm/drm_modes.c
> >> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> >> drm_display_mode *mode1,
> >>mode1->vsync_end == mode2->vsync_end &&
> >>mode1->vtotal == mode2->vtotal &&
> >>mode1->vscan == mode2->vscan &&
> >> +  mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
> >>(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
> >> (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
> >>return true;
> >> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
> >> drm_mode_modeinfo *out,
> >>out->vrefresh = in->vrefresh;
> >>out->flags = in->flags;
> >>out->type = in->type;
> >> +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> >> +
> >> +  switch (in->picture_aspect_ratio) {
> >> +  case HDMI_PICTURE_ASPECT_4_3:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_16_9:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> >> +  break;
> >> +  case HDMI_PICTURE_ASPECT_RESERVED:
> >> +  default:
> >> +  out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> >> +  break;
> >> +  }
> >> +
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   }
> >> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> >> *out,
> >>strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
> >>out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
> >>   
> >> +  /* Clearing picture aspect ratio bits from out flags */
> >> +  out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> >> +
> >> +  switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> >> +  case DRM_MODE_FLAG_PIC_AR_4_3:
> >> +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> >> +  break;
> >> +  case DRM_MODE_FLAG_PIC_AR_16_9:
> >> +  out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> >> +  break;
> >> +  default:
> >> +  out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> >> +  break;
> >> +  }
> > Hmm. So now we have the mode aspect ratio infromation duplicated
> > in two different places. Not sure that won't lead to some confusion.
> In drm layer, this is the only place. Actually till now, DRM layer dint 
> have the support for aspect ratio at all. This was causing
> HDMI compliance tests like 7-27 fail, which expect a particular unique 
> VIC in AVI infoframe on modeset.
> 
> I have given some details about this in cover-letter.
> > Although we do want the user to be able to override via the property I
> > suppose, so we'd have to change that (+ the inforframe code) to
> > look at the mode flags instead if we would eliminate
> > 'picture_aspect_ratio'.
> I had a small discussion on this with Daniel, and we discussed that it 
> doesnt make sense to override just the aspect ratio if the monitor 
> doesn't even support that aspect ratio.
> And currently the was how this property is implemented is, we just 
> override the aspect ratio without any validity check.
> 
> Now as we have all the supported aspect ratio added properly in the mode 
> info itself, we need not to have this property at all, So Daniel 
> suggested me to remove that property too.
> >
> > And that brings me to the other point. At least i915 will simply
> > override the mode's aspect ration with the property. So this looks like
> > a big no-op for now on i915.
> Yes, 

Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 6:04 PM, Jani Nikula wrote:

On Fri, 14 Oct 2016, "Sharma, Shashank"  wrote:

Regards

Shashank


On 10/14/2016 8:02 PM, Jani Nikula wrote:

On Fri, 14 Oct 2016, Shashank Sharma  wrote:

Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driver can
initialize it properly.

This patch adds a utility function, which checks the VBT flag
for lspcon bit, and tells us if a port is configured to have a
lspcon device or not.

V2: Fixed review comments from Ville
- Do not forget PORT_D while checking lspcon for GEN9

V3: Addressed review comments from Rodrigo
- Create a HAS_LSPCON() macro for better use case handling.
- Do not dump warnings for non-gen-9 platforms, it will be noise.

V4: Rebase
V5: Rebase
V6: Pass dev_priv to HAS_LSPCON() macro

Signed-off-by: Shashank Sharma 
Reviewed-by: Rodrigo Vivi 

I was hoping you'd use the version I rebased and sent, put it first in
the series, and rebase the rest on that. The point is, this series has
taken so long that lspcon devices have proliferated all over the place,
and we'll be getting more and more bugs about them. If this patch was
first, with the debug logging, we could at least get that to 4.9, maybe
stable kernels, and we'd immediately know the reason. I think it'll be a
hard sell to get the whole series to 4.9 kernel.

BR,
Jani.

Jani,
The patch got its first r-b since a long time.
After that, it was waiting to be merged, for long time.

Recently, when Imre was asked to test the patches, and he found one
issue specific to APL.
We were trying to fix a suspend-resume issue, which was fixed with the
last patch.
Now this patch is ready to be merged, just waiting for Imre's r-b.

Third patch just gives information about if LSPCON is available or not,
which is not a big help for anything as such.
So instead of changing the sequence, and confusing the reviewers, I
thought it would be better to send the whole series and
get this merged as-it-is.

Fine, let's merge this as-is... after patch 1/5 has been posted to
dri-devel and/or has received an ack from Dave Airlie that it's fine to
merge through our tree.

In the bigger scheme of things, if this patch 3/5 had been first in the
series all along, we could have merged this *months* ago. This is how
series should be organized. Simple things first.
Please note that this was in continuation with Ville's dp_dual_mode 
series, so I had to start series with lspcon support in DP helper layer, 
and then come to I915 layer.

Also, IMHO, It was in the simplest form :).


Having the debug information *is* valuable. You'd see that if you had to
go through our incoming bugs. We've had plenty of LSPCON bugs since the
day Skylake was launched. Yes, quite a long time now. If 3/5 was first
in the series, we could backport that to v4.9 and older and reduce our
debugging time.
I was already debugging the LSPCON issues on SKL for various devices 
(Like Skullcandy), with Paul's team, and they had proper information 
about this series, along with how to detect LSPCON, since the whole time.
They were also waiting for the merge itself, and the progress was 
recorded in this Jira VIZ-2800. Please see the comments from me since 
25th march, and from Manasi on 17th May.
This patch series had r-b since few months, I am not sure what else I 
could have done better.


Regards
Shashank


BR,
Jani.







Regards
Shashank

---
   drivers/gpu/drm/i915/i915_drv.h   |  5 
   drivers/gpu/drm/i915/intel_bios.c | 49 
+++
   2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fe875b2..7bab2f1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
   
   #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
   
+#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))

+
   /* DPF == dynamic parity feature */
   #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
   #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
@@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
drm_i915_private *dev_priv, enum por
   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
+bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
+   enum port port);
+
   
   /* intel_opregion.c */

   #ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8..32e1def 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1763,3 

Re: [Intel-gfx] [PATCH 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Tvrtko Ursulin]

On 17/10/2016 12:31, Chris Wilson wrote:

On Mon, Oct 17, 2016 at 11:55:54AM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 13:18, Chris Wilson wrote:

  static void
-i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
+i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj,
+ struct sg_table *pages)
  {
struct sgt_iter sgt_iter;
struct page *page;
-   int ret;
-   GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
-
-   ret = i915_gem_object_set_to_cpu_domain(obj, true);
-   if (WARN_ON(ret)) {
-   /* In the event of a disaster, abandon all caches and
-* hope for the best.
-*/
-   i915_gem_clflush_object(obj, true);
-   obj->base.read_domains = obj->base.write_domain = 
I915_GEM_DOMAIN_CPU;
-   }
+   __i915_gem_object_release_shmem(obj);

Waiting for the object to become inactive is now gone. It did not
spot that that changed with this patch. Did it?

There's no wait here. We have BUG_ONs today (that remain in place)
to catch trying to free pages that are in use by the GPU. This is just a
change of domains (and I wanted to keep the set-to-cpu-domain asserts,
and avoid the other side effects).


Oh right, makes sense.

  

  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
  {
-   struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
-   const struct drm_i915_gem_object_ops *ops = obj->ops;
-   int ret;
+   int err;
lockdep_assert_held(>base.dev->struct_mutex);
if (obj->mm.pages)
return 0;
-   if (obj->mm.madv != I915_MADV_WILLNEED) {
-   DRM_DEBUG("Attempting to obtain a purgeable object\n");
-   __i915_gem_object_unpin_pages(obj);
-   return -EFAULT;
-   }
-
-   ret = ops->get_pages(obj);
-   if (ret) {
+   err = i915_gem_object_get_pages(obj);
+   if (err)
__i915_gem_object_unpin_pages(obj);
-   return ret;
-   }
-   list_add_tail(>global_list, _priv->mm.unbound_list);

Objects will no longer appear on the unbound list when they have
backing store?

They still do. We don't hold the struct_mutex here, so we defer the
global list tracking to the domain management which is slightly later.


Later as when VMA gets pinned?...


However, there is still a window of opportunity where we have pages
pinned for our use but not yet visible to the shrinker. A bit of
rejigging should be mean we only need to move the unbound upon
pages_pin_count==0 and it will require a spinlock, but that make
actually work out to be less code. But it won't yet reduce the
struct_mutex hold time in the shrinker, so I'm not seeing the upside
yet.


... in which case userspace just creating objects and not touching them 
avoids putting them on bound/unbound lists?



+static bool unsafe_drop_pages(struct drm_i915_gem_object *obj)
+{
+   if (i915_gem_object_unbind(obj) == 0)
+   __i915_gem_object_put_pages(obj);
+   return !obj->mm.pages;
+}

Can we have some comments with this function?

It may or may not result in the pages being freed, and it may or may
result in the object being unreferenced. There used to be a function
called drop_pages (which the same caveats) that got misused so I removed
it and wanted to be sure that they didn't repeat their mistakes.


Hm OK, not that important in this case.

Regards,

Tvrtko

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

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 6:01 PM, Ville Syrjälä wrote:

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too
V3: Rebase
V4: Added r-b from Jose
---
  drivers/gpu/drm/drm_modes.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
  }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
  
+	/* Clearing picture aspect ratio bits from out flags */

+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.
In drm layer, this is the only place. Actually till now, DRM layer dint 
have the support for aspect ratio at all. This was causing
HDMI compliance tests like 7-27 fail, which expect a particular unique 
VIC in AVI infoframe on modeset.


I have given some details about this in cover-letter.

Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.
I had a small discussion on this with Daniel, and we discussed that it 
doesnt make sense to override just the aspect ratio if the monitor 
doesn't even support that aspect ratio.
And currently the was how this property is implemented is, we just 
override the aspect ratio without any validity check.


Now as we have all the supported aspect ratio added properly in the mode 
info itself, we need not to have this property at all, So Daniel 
suggested me to remove that property too.


And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915.
Yes, This is a bug in I915. When I published the first version of this 
series, I had one patch, which was overriding the value only when the 
property is set.
This should be the right case. And then Daniel suggested to remove the 
property all together (and it makes sense as we have proper aspect 
ratios in mode information

itself) So I kept that patch 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/atomic: Use less confusing iterator names.

[Patchwork]

== Series Details ==

Series: drm/atomic: Use less confusing iterator names.
URL   : https://patchwork.freedesktop.org/series/13869/
State : warning

== Summary ==

Series 13869v1 drm/atomic: Use less confusing iterator names.
https://patchwork.freedesktop.org/api/1.0/series/13869/revisions/1/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-b:
dmesg-warn -> PASS   (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-kbl-7200u)
skip   -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2737/

15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 
2016y-10m-16d-23h-15m-00s UTC integration manifest
ea8593b drm/atomic: Use new atomic iterator macros.
57e7629 drm/atomic: Make add_affected_connectors look at crtc_state.
288fbb6 drm/blend: Use new atomic iterator macros.
18176fd drm/exynos: Use new atomic iterator macros.
19b0930 drm/atmel-hlcdc: Use new atomic iterator macros.
caf279e drm/atomic: Add new iterators over all state

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Picture aspect ratio support in DRM layer

[Saarinen, Jani]

> == Series Details ==
> 
> Series: Picture aspect ratio support in DRM layer
> URL   : https://patchwork.freedesktop.org/series/13868/
> State : failure
> 
> == Summary ==
> 
> Series 13868v1 Picture aspect ratio support in DRM layer
> https://patchwork.freedesktop.org/api/1.0/series/13868/revisions/1/mbox/
> 
> Test gem_ringfill:
> Subgroup basic-default-hang:
> pass   -> TIMEOUT(fi-ivb-3770)
> Test kms_flip:
> Subgroup basic-plain-flip:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test kms_force_connector_basic:
> Subgroup force-connector-state:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup force-edid:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup force-load-detect:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup prune-stale-modes:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test kms_frontbuffer_tracking:
> Subgroup basic:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test kms_pipe_crc_basic:
> Subgroup bad-nb-words-1:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup bad-nb-words-3:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup bad-pipe:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup bad-source:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup hang-read-crc-pipe-a:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup hang-read-crc-pipe-b:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup hang-read-crc-pipe-c:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-a:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-b:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-b-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-c:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup nonblocking-crc-pipe-c-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-a:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-b:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-b-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-c:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup read-crc-pipe-c-frame-sequence:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup suspend-read-crc-pipe-a:
> dmesg-warn -> PASS   (fi-byt-j1900)
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup suspend-read-crc-pipe-b:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup suspend-read-crc-pipe-c:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test kms_setmode:
> Subgroup basic-clone-single-crtc:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test kms_sink_crc_basic:
> skip   -> INCOMPLETE (fi-ivb-3770)
> Test pm_backlight:
> Subgroup basic-brightness:
> skip   -> INCOMPLETE (fi-ivb-3770)
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> skip   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-rte:
> skip   -> INCOMPLETE (fi-ivb-3770)
> Test pm_rps:
> Subgroup basic-api:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test prime_busy:
> Subgroup basic-after-default:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-before-default:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-wait-after-default:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-wait-before-default:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Test prime_self_import:
> Subgroup basic-llseek-bad:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-llseek-size:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-with_fd_dup:
> pass   -> INCOMPLETE (fi-ivb-3770)
> Subgroup basic-with_one_bo:
> WARNING: Long output truncated

[182/246] skip: 21, pass: 160, timeout: 1 /
running: igt/kms_flip/basic-plain-flip 

[182/246] skip: 21, pass: 160, timeout: 1 -
Build timed out (after 18 minutes). Marking the build as aborted.

> 
> Results at 

Re: [Intel-gfx] [PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank


On 10/17/2016 5:55 PM, Daniel Vetter wrote:

On Mon, Oct 17, 2016 at 05:34:36PM +0530, Shashank Sharma wrote:

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
   supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
   parse when we read the modes from EDID. But while transforming
   user_mode to kernel_mode or viceversa, DRM layer lose this
   information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
   to contain exact VIC no for the 'video mode under test'. Now CEA
   modes have different VIC for same modes but different aspect ratio
   for example:
 VIC 2 = 720x480@60 4:3
 VIC 3 = 720x480@60 16:9
   In this way, lack of aspect ratio information, can cause wrong VIC
   no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
   also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
   modes.
 - 64:27
 - 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches
V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3

Shashank Sharma (4):
   drm: add picture aspect ratio flags
   drm: Add aspect ratio parsing in DRM layer
   video: Add new aspect ratios for HDMI 2.0
   drm: Add and handle new aspect ratios in DRM layer

Applied to drm-misc, thanks. I guess you'll follow up with i915 patches to
remove the picture aspect ratio for overrides eventually?

Thanks, Daniel
Thanks Daniel, and yes, its in my to-do list to remove the pic aspect 
ratio property, to override, as suggested by you in our last communication.
I was waiting for this series to be merged, so that I can give reference 
of this.


Will add you for the review of the patch,

Regards
Shashank

  drivers/gpu/drm/drm_modes.c | 43 +++
  drivers/video/hdmi.c|  4 
  include/linux/hdmi.h|  2 ++
  include/uapi/drm/drm_mode.h | 24 +++-
  4 files changed, 68 insertions(+), 5 deletions(-)

--
1.9.1

___
dri-devel mailing list
dri-de...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


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

[Intel-gfx] [drm-intel:drm-intel-next-queued 1/1] drivers/gpu/drm/i915/gvt/handlers.c:137:3: note: in expansion of macro 'if'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   06a75ace46e2fdd1d93b06228df0e2dfe526cc27
commit: 06a75ace46e2fdd1d93b06228df0e2dfe526cc27 [1/1] Merge tag 
'gvt-next-2016-10-14' of https://github.com/01org/gvt-linux into 
drm-intel-next-queued
config: x86_64-randconfig-a0-10171253 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 06a75ace46e2fdd1d93b06228df0e2dfe526cc27
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/drm/drm.h:41,
from include/uapi/drm/i915_drm.h:30,
from drivers/gpu/drm/i915/i915_drv.h:33,
from drivers/gpu/drm/i915/gvt/handlers.c:39:
   drivers/gpu/drm/i915/gvt/handlers.c: In function 'render_mmio_to_ring_id':
   drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: 
'gvt->dev_priv->engine[i]' is a pointer; did you mean to use '->'?
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^
  ->
   include/linux/compiler.h:149:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/gvt/handlers.c:137:3: note: in expansion of macro 'if'
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^~
   drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: 
'gvt->dev_priv->engine[i]' is a pointer; did you mean to use '->'?
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^
  ->
   include/linux/compiler.h:149:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/i915/gvt/handlers.c:137:3: note: in expansion of macro 'if'
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^~
   drivers/gpu/drm/i915/gvt/handlers.c:137:31: error: 
'gvt->dev_priv->engine[i]' is a pointer; did you mean to use '->'?
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^
  ->
   include/linux/compiler.h:160:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> drivers/gpu/drm/i915/gvt/handlers.c:137:3: note: in expansion of macro 'if'
  if (gvt->dev_priv->engine[i].mmio_base == reg)
  ^~

vim +/if +137 drivers/gpu/drm/i915/gvt/handlers.c

12d14cc4 Zhi Wang 2016-08-30   33   *Ping Gao 
12d14cc4 Zhi Wang 2016-08-30   34   *Zhi Wang 
12d14cc4 Zhi Wang 2016-08-30   35   *
12d14cc4 Zhi Wang 2016-08-30   36  
12d14cc4 Zhi Wang 2016-08-30   37   */
12d14cc4 Zhi Wang 2016-08-30   38  
12d14cc4 Zhi Wang 2016-08-30  @39  #include "i915_drv.h"
12d14cc4 Zhi Wang 2016-08-30   40  
e39c5add Zhi Wang 2016-09-02   41  /* XXX FIXME i915 has changed PP_XXX 
definition */
e39c5add Zhi Wang 2016-09-02   42  #define PCH_PP_STATUS  _MMIO(0xc7200)
e39c5add Zhi Wang 2016-09-02   43  #define PCH_PP_CONTROL _MMIO(0xc7204)
e39c5add Zhi Wang 2016-09-02   44  #define PCH_PP_ON_DELAYS _MMIO(0xc7208)
e39c5add Zhi Wang 2016-09-02   45  #define PCH_PP_OFF_DELAYS _MMIO(0xc720c)
e39c5add Zhi Wang 2016-09-02   46  #define PCH_PP_DIVISOR _MMIO(0xc7210)
e39c5add Zhi Wang 2016-09-02   47  
12d14cc4 Zhi Wang 2016-08-30   48  /* Register contains RO bits */
12d14cc4 Zhi Wang 2016-08-30   49  #define F_RO (1 << 0)
12d14cc4 Zhi Wang 2016-08-30   50  /* Register contains graphics address */
12d14cc4 Zhi Wang 2016-08-30   51  #define F_GMADR  (1 << 1)
12d14cc4 Zhi Wang 2016-08-30   52  /* Mode mask registers with high 16 bits as 
the mask bits */
12d14cc4 Zhi Wang 2016-08-30   53  #define F_MODE_MASK  (1 << 2)
12d14cc4 Zhi Wang 2016-08-30   54  /* This reg can be accessed by GPU commands 
*/
12d14cc4 Zhi Wang 2016-08-30   55  #define F_CMD_ACCESS (1 << 3)
12d14cc4 Zhi Wang 2016-08-30   56  /* This reg has been accessed by a VM */
12d14cc4 Zhi Wang 2016-08-30   57  #define F_ACCESSED   (1 << 4)
12d14cc4 Zhi Wang 2016-08-30   58  /* This reg has been accessed through GPU 
commands */
12d14cc4 Zhi Wang 2016-08-30   59  #define F_CMD_ACCESSED   (1 << 5)
12d14cc4 Zhi Wang 2016-08-30   60  /* This reg could be accessed by unaligned 
address */
12d14cc4 Zhi Wang 2016-08-30   61  #define F_UNALIGN(1 << 6)
12d14cc4 Zhi Wang 2016-08-30   62  
12d14cc4 Zhi Wang 2016-08-30   63  unsigned long 
intel_gvt_get_device_type(struct intel_gvt *gvt)
12d14cc4 Zhi Wang 2016-08-30   64  {
12d14cc4 Zhi Wang 2016-08-30   65   if (IS_BROADWELL(gvt->dev_priv))
12d14cc4 Zhi Wang 2016-08-30 

[Intel-gfx] ✗ Fi.CI.BAT: failure for Picture aspect ratio support in DRM layer

[Patchwork]

== Series Details ==

Series: Picture aspect ratio support in DRM layer
URL   : https://patchwork.freedesktop.org/series/13868/
State : failure

== Summary ==

Series 13868v1 Picture aspect ratio support in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/13868/revisions/1/mbox/

Test gem_ringfill:
Subgroup basic-default-hang:
pass   -> TIMEOUT(fi-ivb-3770)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup force-edid:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup force-load-detect:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup prune-stale-modes:
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_pipe_crc_basic:
Subgroup bad-nb-words-1:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup bad-nb-words-3:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup bad-pipe:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup bad-source:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup hang-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup hang-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup hang-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-a:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-b:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-b-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-c:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup nonblocking-crc-pipe-c-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-a:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-b:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-c:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup read-crc-pipe-c-frame-sequence:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-a:
dmesg-warn -> PASS   (fi-byt-j1900)
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-b:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup suspend-read-crc-pipe-c:
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_setmode:
Subgroup basic-clone-single-crtc:
pass   -> INCOMPLETE (fi-ivb-3770)
Test kms_sink_crc_basic:
skip   -> INCOMPLETE (fi-ivb-3770)
Test pm_backlight:
Subgroup basic-brightness:
skip   -> INCOMPLETE (fi-ivb-3770)
Test pm_rpm:
Subgroup basic-pci-d3-state:
skip   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-rte:
skip   -> INCOMPLETE (fi-ivb-3770)
Test pm_rps:
Subgroup basic-api:
pass   -> INCOMPLETE (fi-ivb-3770)
Test prime_busy:
Subgroup basic-after-default:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-before-default:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-wait-after-default:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-wait-before-default:
pass   -> INCOMPLETE (fi-ivb-3770)
Test prime_self_import:
Subgroup basic-llseek-bad:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-llseek-size:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-with_fd_dup:
pass   -> INCOMPLETE (fi-ivb-3770)
Subgroup basic-with_one_bo:
WARNING: Long output truncated

Results at /archive/results/CI_IGT_test/Patchwork_2736/

15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 
2016y-10m-16d-23h-15m-00s UTC integration manifest
a34f927 drm: Add and handle new aspect ratios in DRM layer
293026e video: Add new aspect ratios for HDMI 2.0
1711ac2 drm: Add aspect ratio parsing in DRM layer
93ba751 drm: add picture aspect ratio flags

___
Intel-gfx mailing 

[Intel-gfx] [PATCH] intel-ci: Add gem_exec_suspend/basic-S3/S4-devices to BAT

[Imre Deak]

Add gem_exec_suspend/basic-s3-devices and basic-s4-devices subtests to
BAT. At the same time remove basic-s4 from the list, which is atm
implicitly disabled via HIBERNATION=n in kconfig. We would need at least
basic S4 coverage provided by basic-s4-devices, which requires
HIBERNATION=y.

Signed-off-by: Imre Deak 
---
 tests/intel-ci/fast-feedback.testlist | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index f59ec98..efa7e86 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -73,8 +73,9 @@ igt@gem_exec_store@basic-default
 igt@gem_exec_store@basic-render
 igt@gem_exec_store@basic-vebox
 igt@gem_exec_suspend@basic
+igt@gem_exec_suspend@basic-s3-devices
 igt@gem_exec_suspend@basic-s3
-igt@gem_exec_suspend@basic-s4
+igt@gem_exec_suspend@basic-s4-devices
 igt@gem_flink_basic@bad-flink
 igt@gem_flink_basic@bad-open
 igt@gem_flink_basic@basic
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH v4 3/4] video: Add new aspect ratios for HDMI 2.0

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 05:34:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
> 
> This patch adds enumeration for the new aspect ratios
> in the existing aspect ratio list.
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Sean Paul 
> Reviewed-by: Jose Abreu 
> Acked-by: Tomi Valkeinen 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> 
> V2: rebase
> V3: rebase
> V4: Added r-b from Jose, Ack by Tomi
> ---
>  drivers/video/hdmi.c | 4 
>  include/linux/hdmi.h | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 1626892..1cf907e 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
> picture_aspect)
>   return "4:3";
>   case HDMI_PICTURE_ASPECT_16_9:
>   return "16:9";
> + case HDMI_PICTURE_ASPECT_64_27:
> + return "64:27";
> + case HDMI_PICTURE_ASPECT_256_135:
> + return "256:135";
>   case HDMI_PICTURE_ASPECT_RESERVED:
>   return "Reserved";
>   }
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index e974420..edbb4fc 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
>   HDMI_PICTURE_ASPECT_NONE,
>   HDMI_PICTURE_ASPECT_4_3,
>   HDMI_PICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,

Hmm. How's this gonna work? The AVI infoframe doesn't have these.

>   HDMI_PICTURE_ASPECT_RESERVED,
>  };
>  
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH 14/19] drm/mediatek: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index db61aa5f32ef..414e848d8cbf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -50,8 +50,8 @@ static void mtk_atomic_wait_for_fences(struct 
drm_atomic_state *state)
struct drm_plane_state *plane_state;
int i;
 
-   for_each_plane_in_state(state, plane, plane_state, i)
-   mtk_fb_wait(plane->state->fb);
+   for_each_new_plane_in_state(state, plane, plane_state, i)
+   mtk_fb_wait(plane_state->fb);
 }
 
 static void mtk_atomic_complete(struct mtk_drm_private *private,
-- 
2.7.4

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

[Intel-gfx] [PATCH 03/19] drm/exynos: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4a21a745c373..fc54f3f0a42c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -243,7 +243,7 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
drm_atomic_state *state,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);
 
wait_event(priv->wait, !commit_is_pending(priv, commit->crtcs));
-- 
2.7.4

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

[Intel-gfx] [PATCH 00/19] drm/atomic: Use less confusing iterator names.

[Maarten Lankhorst]

Add for_each_(old,new)_(crtc,connector,plane)_in_state iterators, and
re-use for_each_*_in_state to be a iterator with the old and the new
state.

This will be less confusing than the previous case, in which
for_each_*_in_state could refer to the old or the new state.

The oldnew macro names are temporary in this series, until
all drivers are converted to use the old, new or both states.

This series applies to the topic/drm-misc branch, and will probably
conflict with a lot of other stuff. This is why I post this right
after the merge window.

Compile tested on arm and tested for i915 on x86.

Maarten Lankhorst (19):
  drm/atomic: Add new iterators over all state
  drm/atmel-hlcdc: Use new atomic iterator macros.
  drm/exynos: Use new atomic iterator macros.
  drm/blend: Use new atomic iterator macros.
  drm/atomic: Make add_affected_connectors look at crtc_state.
  drm/atomic: Use new atomic iterator macros.
  drm/atomic: Fix atomic helpers to use the new iterator macros.
  drm/vc4: Use new atomic iterator macros.
  drm/rockchip: Use new atomic iterator macros.
  drm/rcar-du: Use new atomic iterator macros.
  drm/omap: Use new atomic iterator macros
  drm/msm: Use new atomic iterator macros
  drm/imx: Use new atomic iterator macros
  drm/mediatek: Use new atomic iterator macros
  drm/i915: Use new atomic iterator macros in ddi
  drm/i915: Use new atomic iterator macros in fbc
  drm/i915: Use new atomic iterator macros in wm code
  drm/i915: Use new atomic iterator macros in display code
  drm/atomic: Rename atomic oldnew iterator

 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c |   2 +-
 drivers/gpu/drm/drm_atomic.c   |  27 +-
 drivers/gpu/drm/drm_atomic_helper.c| 354 ++---
 drivers/gpu/drm/drm_blend.c|  22 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   2 +-
 drivers/gpu/drm/i915/intel_ddi.c   |   4 +-
 drivers/gpu/drm/i915/intel_display.c   | 167 ++--
 drivers/gpu/drm/i915/intel_drv.h   |   2 -
 drivers/gpu/drm/i915/intel_fbc.c   |   6 +-
 drivers/gpu/drm/i915/intel_pm.c|  12 +-
 drivers/gpu/drm/imx/imx-drm-core.c |  10 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |   4 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c|   4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c|   6 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h|   3 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c  |   4 +-
 drivers/gpu/drm/msm/msm_atomic.c   |  16 +-
 drivers/gpu/drm/omapdrm/omap_drv.c |   8 +-
 drivers/gpu/drm/rcar-du/rcar_du_kms.c  |   2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c|   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|   6 +-
 drivers/gpu/drm/vc4/vc4_kms.c  |   6 +-
 include/drm/drm_atomic.h   |  83 --
 include/drm/drm_atomic_helper.h|   3 +
 24 files changed, 442 insertions(+), 315 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 16/19] drm/i915: Use new atomic iterator macros in fbc

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index faa67624e1ed..0028335fc1bb 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1060,7 +1060,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
 
mutex_lock(>lock);
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (fbc->crtc == to_intel_crtc(crtc)) {
fbc_crtc_present = true;
break;
@@ -1074,14 +1074,14 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
*dev_priv,
 * plane. We could go for fancier schemes such as checking the plane
 * size, but this would just affect the few platforms that don't tie FBC
 * to pipe or plane A. */
-   for_each_plane_in_state(state, plane, plane_state, i) {
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
struct intel_plane_state *intel_plane_state =
to_intel_plane_state(plane_state);
 
if (!intel_plane_state->base.visible)
continue;
 
-   for_each_crtc_in_state(state, crtc, crtc_state, j) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, j) {
struct intel_crtc_state *intel_crtc_state =
to_intel_crtc_state(crtc_state);
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 17/19] drm/i915: Use new atomic iterator macros in wm code

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2df06b703e3d..163b73b493bf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3227,7 +3227,7 @@ skl_get_total_relative_data_rate(struct intel_crtc_state 
*intel_cstate)
return 0;
 
/* Calculate and cache data rate for each plane */
-   for_each_plane_in_state(state, plane, pstate, i) {
+   for_each_new_plane_in_state(state, plane, pstate, i) {
id = skl_wm_plane_id(to_intel_plane(plane));
intel_plane = to_intel_plane(plane);
 
@@ -3364,14 +3364,14 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
alloc_size -= cursor_blocks;
 
/* 1. Allocate the mininum required blocks for each active plane */
-   for_each_plane_in_state(state, plane, pstate, i) {
+   for_each_new_plane_in_state(state, plane, pstate, i) {
intel_plane = to_intel_plane(plane);
id = skl_wm_plane_id(intel_plane);
 
if (intel_plane->pipe != pipe)
continue;
 
-   if (!to_intel_plane_state(pstate)->base.visible) {
+   if (!pstate->visible) {
minimum[id] = 0;
y_minimum[id] = 0;
continue;
@@ -3933,7 +3933,7 @@ pipes_modified(struct drm_atomic_state *state)
struct drm_crtc_state *cstate;
uint32_t i, ret = 0;
 
-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
ret |= drm_crtc_mask(crtc);
 
return ret;
@@ -4048,7 +4048,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * since any racing commits that want to update them would need to
 * hold _all_ CRTC state mutexes.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i)
+   for_each_new_crtc_in_state(state, crtc, cstate, i)
changed = true;
if (!changed)
return 0;
@@ -4070,7 +4070,7 @@ skl_compute_wm(struct drm_atomic_state *state)
 * should allow skl_update_pipe_wm() to return failure in cases where
 * no suitable watermark values can be found.
 */
-   for_each_crtc_in_state(state, crtc, cstate, i) {
+   for_each_new_crtc_in_state(state, crtc, cstate, i) {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_crtc_state *intel_cstate =
to_intel_crtc_state(cstate);
-- 
2.7.4

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

[Intel-gfx] [PATCH 06/19] drm/atomic: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 1915ec44f7eb..6672ea93ee73 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1369,7 +1369,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
 
DRM_DEBUG_ATOMIC("checking %p\n", state);
 
-   for_each_plane_in_state(state, plane, plane_state, i) {
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
ret = drm_atomic_plane_check(plane, plane_state);
if (ret) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] atomic core check 
failed\n",
@@ -1378,7 +1378,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
}
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
ret = drm_atomic_crtc_check(crtc, crtc_state);
if (ret) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] atomic core check 
failed\n",
@@ -1391,7 +1391,7 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
ret = config->funcs->atomic_check(state->dev, state);
 
if (!state->allow_modeset) {
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] requires full 
modeset\n",
 crtc->base.id, crtc->name);
@@ -1732,7 +1732,7 @@ retry:
}
 
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
struct drm_pending_vblank_event *e;
 
e = create_vblank_event(dev, file_priv, NULL,
@@ -1768,7 +1768,7 @@ out:
 * for TEST_ONLY too.
 */
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
if (!crtc_state->event)
continue;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 11/19] drm/omap: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/omapdrm/omap_drv.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 1735c7accf72..74f9519878a2 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -69,13 +69,13 @@ struct omap_atomic_state_commit {
 static void omap_atomic_wait_for_completion(struct drm_device *dev,
struct drm_atomic_state *old_state)
 {
-   struct drm_crtc_state *old_crtc_state;
+   struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
unsigned int i;
int ret;
 
-   for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+   if (!crtc_state->enable)
continue;
 
ret = omap_crtc_wait_pending(crtc);
@@ -164,7 +164,7 @@ static int omap_atomic_commit(struct drm_device *dev,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);
 
wait_event(priv->commit.wait, !omap_atomic_is_pending(priv, commit));
-- 
2.7.4

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

[Intel-gfx] [PATCH 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

[Maarten Lankhorst]

This kills another dereference of connector->state. connector_mask
holds all unchanged connectors at least and any changed connectors
are already in state anyway.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 120775fcfb70..1915ec44f7eb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1230,8 +1230,13 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
struct drm_mode_config *config = >dev->mode_config;
struct drm_connector *connector;
struct drm_connector_state *conn_state;
+   struct drm_crtc_state *crtc_state;
int ret;
 
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
if (ret)
return ret;
@@ -1240,11 +1245,11 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
 crtc->base.id, crtc->name, state);
 
/*
-* Changed connectors are already in @state, so only need to look at the
-* current configuration.
+* Changed connectors are already in @state, so only need to look
+* at the connector_mask in crtc_state.
 */
drm_for_each_connector(connector, state->dev) {
-   if (connector->state->crtc != crtc)
+   if (!(crtc_state->connector_mask & (1 << 
drm_connector_index(connector
continue;
 
conn_state = drm_atomic_get_connector_state(state, connector);
-- 
2.7.4

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

[Intel-gfx] [PATCH 10/19] drm/rcar-du: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c76ed9ee6a01..153dafac753c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -312,7 +312,7 @@ static int rcar_du_atomic_commit(struct drm_device *dev,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);
 
spin_lock(>commit.wait.lock);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index a74f8ed8ca2e..b8c35ad9db34 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -144,7 +144,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
struct drm_plane_state *drm_plane_state;
 
/* Check if hardware planes need to be reallocated. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int index;
@@ -246,7 +246,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
}
 
/* Reallocate hardware planes for each plane that needs it. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int crtc_planes;
-- 
2.7.4

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

[Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Maarten Lankhorst]

Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
replace the old for_each_xxx_in_state ones. This is useful for >1 flip
depth and getting rid of all xxx->state dereferences.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c |  6 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
 drivers/gpu/drm/i915/intel_display.c | 11 ++---
 include/drm/drm_atomic.h | 81 ++--
 include/drm/drm_atomic_helper.h  |  3 ++
 5 files changed, 142 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5dd70540219c..120775fcfb70 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
return ERR_PTR(-ENOMEM);
 
state->crtcs[index].state = crtc_state;
+   state->crtcs[index].old_state = crtc->state;
+   state->crtcs[index].new_state = crtc_state;
state->crtcs[index].ptr = crtc;
crtc_state->state = state;
 
@@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
 
state->planes[index].state = plane_state;
state->planes[index].ptr = plane;
+   state->planes[index].old_state = plane->state;
+   state->planes[index].new_state = plane_state;
plane_state->state = state;
 
DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
@@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
 
drm_connector_reference(connector);
state->connectors[index].state = connector_state;
+   state->connectors[index].old_state = connector->state;
+   state->connectors[index].new_state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 07b432f43b98..fcb6e5b55217 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
  *
  * See also:
  * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
- * drm_atomic_helper_resume()
+ * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
  */
 struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
 {
@@ -2536,6 +2536,52 @@ unlock:
 EXPORT_SYMBOL(drm_atomic_helper_suspend);
 
 /**
+ * drm_atomic_helper_commit_duplicated_state - commit duplicated state
+ * @state: duplicated atomic state to commit
+ * @ctx: pointer to acquire_ctx to use for commit.
+ * @nonblock: commit the state non-blocking.
+ *
+ * The state returned by drm_atomic_helper_duplicate_state() and
+ * drm_atomic_helper_suspend() is partially invalid, and needs to
+ * be fixed up before commit.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ *
+ * See also:
+ * drm_atomic_helper_suspend()
+ */
+int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
+ struct drm_modeset_acquire_ctx 
*ctx,
+ bool nonblock)
+{
+   int i;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+
+   state->acquire_ctx = ctx;
+
+   for_each_new_plane_in_state(state, plane, plane_state, i)
+   state->planes[i].old_state = plane->state;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+   state->crtcs[i].old_state = crtc->state;
+
+   for_each_new_connector_in_state(state, connector, conn_state, i)
+   state->connectors[i].old_state = connector->state;
+
+   if (nonblock)
+   return drm_atomic_nonblocking_commit(state);
+   else
+   return drm_atomic_commit(state);
+}
+EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
+
+/**
  * drm_atomic_helper_resume - subsystem-level resume helper
  * @dev: DRM device
  * @state: atomic state to resume to
@@ -2558,9 +2604,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
int err;
 
drm_mode_config_reset(dev);
+
drm_modeset_lock_all(dev);
-   state->acquire_ctx = config->acquire_ctx;
-   err = drm_atomic_commit(state);
+   err = drm_atomic_helper_commit_duplicated_state(state, 
config->acquire_ctx, false);
drm_modeset_unlock_all(dev);
 
return err;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a12e093c54cf..3bd3f6a93c12 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3497,7 +3497,8 @@ static void 

[Intel-gfx] [PATCH 04/19] drm/blend: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_blend.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 85172a977bf3..70c03eb032fc 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -367,27 +367,27 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
int i, ret = 0;
 
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   crtc = plane_state->crtc;
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   crtc = new_plane_state->crtc;
if (!crtc)
continue;
-   if (plane->state->zpos != plane_state->zpos) {
-   crtc_state =
+   if (old_plane_state->zpos != new_plane_state->zpos) {
+   new_crtc_state =
drm_atomic_get_existing_crtc_state(state, crtc);
-   crtc_state->zpos_changed = true;
+   new_crtc_state->zpos_changed = true;
}
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (crtc_state->plane_mask != crtc->state->plane_mask ||
-   crtc_state->zpos_changed) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
+   new_crtc_state->zpos_changed) {
ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
-   crtc_state);
+   
new_crtc_state);
if (ret)
return ret;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 08/19] drm/vc4: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index f31f72af8551..76cc9b374215 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -111,7 +111,7 @@ static int vc4_atomic_commit(struct drm_device *dev,
uint64_t wait_seqno = 0;
struct vc4_commit *c;
struct drm_plane *plane;
-   struct drm_plane_state *new_state;
+   struct drm_plane_state *old_state, *new_state;
 
c = commit_init(state);
if (!c)
@@ -139,8 +139,8 @@ static int vc4_atomic_commit(struct drm_device *dev,
return ret;
}
 
-   for_each_plane_in_state(state, plane, new_state, i) {
-   if ((plane->state->fb != new_state->fb) && new_state->fb) {
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i) {
+   if (old_state->fb != new_state->fb && new_state->fb) {
struct drm_gem_cma_object *cma_bo =
drm_fb_cma_get_gem_obj(new_state->fb, 0);
struct vc4_bo *bo = to_vc4_bo(_bo->base);
-- 
2.7.4

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

[Intel-gfx] [PATCH 02/19] drm/atmel-hlcdc: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9b17a66cf0e1..b5af77097033 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -268,7 +268,7 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
drm_crtc_state *state)
 
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
 
-   for_each_connector_in_state(state->state, connector, cstate, i) {
+   for_each_new_connector_in_state(state->state, connector, cstate, i) {
struct drm_display_info *info = >display_info;
unsigned int supported_fmts = 0;
int j;
-- 
2.7.4

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

[Intel-gfx] [PATCH 19/19] drm/atomic: Rename atomic oldnew iterator

[Maarten Lankhorst]

With the old users of for_each_obj_in_state gone, we can rename
for_each_oldnew_obj_in_state back to that name. It's slightly less
ugly.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 34 ++---
 drivers/gpu/drm/drm_blend.c |  4 ++--
 drivers/gpu/drm/i915/intel_display.c| 16 +++---
 drivers/gpu/drm/imx/imx-drm-core.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_atomic.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c   |  2 +-
 include/drm/drm_atomic.h| 30 +++--
 9 files changed, 35 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c8aba493fc17..8fb955181641 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -241,7 +241,7 @@ steal_encoder(struct drm_atomic_state *state,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
if (new_connector_state->best_encoder != encoder)
@@ -482,7 +482,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i, ret;
 
-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
if (!drm_mode_equal(_crtc_state->mode, 
_crtc_state->mode)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
 crtc->base.id, crtc->name);
@@ -510,7 +510,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (ret)
return ret;
 
-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
/*
 * This only sets crtc->connectors_changed for routing changes,
 * drivers must set crtc->connectors_changed themselves when
@@ -529,7 +529,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 * configuration. This must be done before calling mode_fixup in case a
 * crtc only changed its mode but has the same set of connectors.
 */
-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
bool has_connectors =
!!new_crtc_state->connector_mask;
 
@@ -685,7 +685,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int i;
 
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
const struct drm_encoder_helper_funcs *funcs;
struct drm_encoder *encoder;
 
@@ -733,7 +733,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
drm_bridge_post_disable(encoder->bridge);
}
 
-   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, 
i) {
const struct drm_crtc_helper_funcs *funcs;
 
/* Shut down everything that needs a full modeset. */
@@ -785,7 +785,7 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
drm_device *dev,
int i;
 
/* clear out existing links and update dpms */
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
if (connector->encoder) {
WARN_ON(!connector->encoder->crtc);
 
@@ -1074,7 +1074,7 @@ bool drm_atomic_helper_framebuffer_changed(struct 
drm_device *dev,
struct drm_plane_state *old_plane_state, *new_plane_state;
int i;
 
-   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
+   for_each_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (new_plane_state->crtc != crtc &&
old_plane_state->crtc != crtc)
  

[Intel-gfx] [PATCH 09/19] drm/rockchip: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..5c0625e5dca1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1009,7 +1009,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct drm_atomic_state *old_state = old_crtc_state->state;
-   struct drm_plane_state *old_plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct vop *vop = to_vop(crtc);
struct drm_plane *plane;
int i;
@@ -1040,11 +1040,11 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
spin_unlock_irq(>dev->event_lock);
 
-   for_each_plane_in_state(old_state, plane, old_plane_state, i) {
+   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (!old_plane_state->fb)
continue;
 
-   if (old_plane_state->fb == plane->state->fb)
+   if (old_plane_state->fb == new_plane_state->fb)
continue;
 
drm_framebuffer_reference(old_plane_state->fb);
-- 
2.7.4

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

[Intel-gfx] [PATCH 12/19] drm/msm: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  4 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  6 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  4 ++--
 drivers/gpu/drm/msm/msm_atomic.c  | 16 
 5 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 571a91ee9607..d18d0a0e0a35 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -113,7 +113,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, struct 
drm_atomic_state *st
mdp4_enable(mdp4_kms);
 
/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_get(crtc);
 }
 
@@ -125,7 +125,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
struct drm_crtc_state *crtc_state;
 
/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_put(crtc);
 
mdp4_disable(mdp4_kms);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index ed7143d35b25..7cfeb0455039 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -82,10 +82,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_state, *new_state;
 
-   for_each_plane_in_state(state, plane, plane_state, i)
-   mdp5_plane_complete_commit(plane, plane_state);
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i)
+   mdp5_plane_complete_commit(plane, old_state, new_state);
 
mdp5_disable(mdp5_kms);
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 03738927be10..90e80619fc54 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -198,7 +198,8 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
 void mdp5_plane_complete_flip(struct drm_plane *plane);
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state);
+   struct drm_plane_state *old_state,
+   struct drm_plane_state *new_state);
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..19c44b968f4e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -859,13 +859,13 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
 
 /* called after vsync in thread context */
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state)
+   struct drm_plane_state *old_state, struct drm_plane_state *new_state)
 {
struct mdp5_kms *mdp5_kms = get_kms(plane);
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
enum mdp5_pipe pipe = mdp5_plane->pipe;
 
-   if (!plane_enabled(plane->state) && mdp5_kms->smp) {
+   if (!plane_enabled(new_state) && mdp5_kms->smp) {
DBG("%s: free SMP", mdp5_plane->name);
mdp5_smp_release(mdp5_kms->smp, pipe);
}
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index db193f835298..333c379e6561 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -89,8 +89,8 @@ static void msm_atomic_wait_for_commit_done(struct drm_device 
*dev,
struct msm_kms *kms = priv->kms;
int i;
 
-   for_each_crtc_in_state(old_state, crtc, crtc_state, i) {
-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+   if (!crtc_state->enable)
continue;
 
/* Legacy cursor ioctls are completely unsynced, and userspace
@@ -191,7 +191,7 @@ int msm_atomic_commit(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *new_plane_state, *old_plane_state;
int i, ret;
 
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -207,18 +207,18 @@ int 

[Intel-gfx] [PATCH 13/19] drm/imx: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 98df09c2b388..d484af773460 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -155,7 +155,7 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 struct drm_atomic_state *state,
 bool nonblock)
 {
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_plane *plane;
struct dma_buf *dma_buf;
int i;
@@ -164,13 +164,13 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 * If the plane fb has an dma-buf attached, fish out the exclusive
 * fence for the atomic helper to wait on.
 */
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
-   dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   if ((old_plane_state->fb != new_plane_state->fb) && 
new_plane_state->fb) {
+   dma_buf = drm_fb_cma_get_gem_obj(new_plane_state->fb,
 0)->base.dma_buf;
if (!dma_buf)
continue;
-   plane_state->fence =
+   new_plane_state->fence =
reservation_object_get_excl_rcu(dma_buf->resv);
}
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 302 +++-
 1 file changed, 157 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fcb6e5b55217..c8aba493fc17 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -103,7 +103,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 * part of the state. If the same encoder is assigned to multiple
 * connectors bail out.
 */
-   for_each_connector_in_state(state, connector, conn_state, i) {
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
 
@@ -238,22 +238,22 @@ steal_encoder(struct drm_atomic_state *state,
 {
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
+   struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
-   if (connector_state->best_encoder != encoder)
+   if (new_connector_state->best_encoder != encoder)
continue;
 
-   encoder_crtc = connector->state->crtc;
+   encoder_crtc = old_connector_state->crtc;
 
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
stealing it\n",
 encoder->base.id, encoder->name,
 encoder_crtc->base.id, encoder_crtc->name);
 
-   set_best_encoder(state, connector_state, NULL);
+   set_best_encoder(state, new_connector_state, NULL);
 
crtc_state = drm_atomic_get_existing_crtc_state(state, 
encoder_crtc);
crtc_state->connectors_changed = true;
@@ -265,7 +265,8 @@ steal_encoder(struct drm_atomic_state *state,
 static int
 update_connector_routing(struct drm_atomic_state *state,
 struct drm_connector *connector,
-struct drm_connector_state *connector_state)
+struct drm_connector_state *old_connector_state,
+struct drm_connector_state *new_connector_state)
 {
const struct drm_connector_helper_funcs *funcs;
struct drm_encoder *new_encoder;
@@ -275,24 +276,24 @@ update_connector_routing(struct drm_atomic_state *state,
 connector->base.id,
 connector->name);
 
-   if (connector->state->crtc != connector_state->crtc) {
-   if (connector->state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
connector->state->crtc);
+   if (old_connector_state->crtc != new_connector_state->crtc) {
+   if (old_connector_state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
old_connector_state->crtc);
crtc_state->connectors_changed = true;
}
 
-   if (connector_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
connector_state->crtc);
+   if (new_connector_state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_connector_state->crtc);
crtc_state->connectors_changed = true;
}
}
 
-   if (!connector_state->crtc) {
+   if (!new_connector_state->crtc) {
DRM_DEBUG_ATOMIC("Disabling [CONNECTOR:%d:%s]\n",
connector->base.id,
connector->name);
 
-   set_best_encoder(state, connector_state, NULL);
+   set_best_encoder(state, new_connector_state, NULL);
 
return 0;
}
@@ -301,7 +302,7 @@ update_connector_routing(struct drm_atomic_state *state,
 
if (funcs->atomic_best_encoder)
new_encoder = funcs->atomic_best_encoder(connector,
-connector_state);
+new_connector_state);
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
@@ -314,33 +315,33 @@ update_connector_routing(struct drm_atomic_state *state,
return -EINVAL;
}
 
-   if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
+   if (!drm_encoder_crtc_ok(new_encoder, new_connector_state->crtc)) {
  

[Intel-gfx] [PATCH 15/19] drm/i915: Use new atomic iterator macros in ddi

[Maarten Lankhorst]

Also make the function static, it's only used inside intel_ddi.c

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 15d47c87def6..0e79c84e14e0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -740,7 +740,7 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
return ret;
 }
 
-struct intel_encoder *
+static struct intel_encoder *
 intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -753,7 +753,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
*crtc_state)
 
state = crtc_state->base.state;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_new_connector_in_state(state, connector, connector_state, i) {
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..588d8af68043 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1156,8 +1156,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
*intel_dp);
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config);
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
 
 void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
 void intel_ddi_clock_get(struct intel_encoder *encoder,
-- 
2.7.4

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

[Intel-gfx] [PATCH 18/19] drm/i915: Use new atomic iterator macros in display code

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 156 ++-
 1 file changed, 80 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3bd3f6a93c12..d310abace86a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3510,7 +3510,12 @@ __intel_display_resume(struct drm_device *dev,
if (!state)
return 0;
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   /*
+* We've duplicated the state, pointers to the old state are invalid.
+*
+* Don't attempt to use the old state until we commit the duplicated 
state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
/*
 * Force recalculation even if we restore
 * current state. With fast modeset this may not result
@@ -5078,13 +5083,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
}
 }
 
-static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
+static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
+  struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->base.state);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
@@ -5186,12 +5190,11 @@ static void intel_encoders_pre_pll_enable(struct 
drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5207,12 +5210,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
*crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5228,12 +5230,11 @@ static void intel_encoders_enable(struct drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5253,7 +5254,7 @@ static void intel_encoders_disable(struct drm_crtc *crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5273,7 +5274,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
*crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5293,7 +5294,7 @@ static void intel_encoders_post_pll_disable(struct 
drm_crtc *crtc,
struct drm_connector *conn;
int i;
 
-   

Re: [Intel-gfx] [PATCH v6 3/5] drm/i915: Parse VBT data for lspcon

[Jani Nikula]

On Fri, 14 Oct 2016, "Sharma, Shashank"  wrote:
> Regards
>
> Shashank
>
>
> On 10/14/2016 8:02 PM, Jani Nikula wrote:
>> On Fri, 14 Oct 2016, Shashank Sharma  wrote:
>>> Many GEN9 boards come with on-board lspcon cards.
>>> Fot these boards, VBT configuration should properly point out
>>> if a particular port contains lspcon device, so that driver can
>>> initialize it properly.
>>>
>>> This patch adds a utility function, which checks the VBT flag
>>> for lspcon bit, and tells us if a port is configured to have a
>>> lspcon device or not.
>>>
>>> V2: Fixed review comments from Ville
>>> - Do not forget PORT_D while checking lspcon for GEN9
>>>
>>> V3: Addressed review comments from Rodrigo
>>> - Create a HAS_LSPCON() macro for better use case handling.
>>> - Do not dump warnings for non-gen-9 platforms, it will be noise.
>>>
>>> V4: Rebase
>>> V5: Rebase
>>> V6: Pass dev_priv to HAS_LSPCON() macro
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Reviewed-by: Rodrigo Vivi 
>> I was hoping you'd use the version I rebased and sent, put it first in
>> the series, and rebase the rest on that. The point is, this series has
>> taken so long that lspcon devices have proliferated all over the place,
>> and we'll be getting more and more bugs about them. If this patch was
>> first, with the debug logging, we could at least get that to 4.9, maybe
>> stable kernels, and we'd immediately know the reason. I think it'll be a
>> hard sell to get the whole series to 4.9 kernel.
>>
>> BR,
>> Jani.
> Jani,
> The patch got its first r-b since a long time.
> After that, it was waiting to be merged, for long time.
>
> Recently, when Imre was asked to test the patches, and he found one 
> issue specific to APL.
> We were trying to fix a suspend-resume issue, which was fixed with the 
> last patch.
> Now this patch is ready to be merged, just waiting for Imre's r-b.
>
> Third patch just gives information about if LSPCON is available or not, 
> which is not a big help for anything as such.
> So instead of changing the sequence, and confusing the reviewers, I 
> thought it would be better to send the whole series and
> get this merged as-it-is.

Fine, let's merge this as-is... after patch 1/5 has been posted to
dri-devel and/or has received an ack from Dave Airlie that it's fine to
merge through our tree.

In the bigger scheme of things, if this patch 3/5 had been first in the
series all along, we could have merged this *months* ago. This is how
series should be organized. Simple things first.

Having the debug information *is* valuable. You'd see that if you had to
go through our incoming bugs. We've had plenty of LSPCON bugs since the
day Skylake was launched. Yes, quite a long time now. If 3/5 was first
in the series, we could backport that to v4.9 and older and reduce our
debugging time.

BR,
Jani.






>
> Regards
> Shashank
>>
>>> ---
>>>   drivers/gpu/drm/i915/i915_drv.h   |  5 
>>>   drivers/gpu/drm/i915/intel_bios.c | 49 
>>> +++
>>>   2 files changed, 54 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index fe875b2..7bab2f1 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
>>>   
>>>   #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
>>>   
>>> +#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))
>>> +
>>>   /* DPF == dynamic parity feature */
>>>   #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
>>>   #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
>>> @@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
>>> drm_i915_private *dev_priv, enum por
>>>   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum 
>>> port *port);
>>>   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>>>  enum port port);
>>> +bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
>>> +   enum port port);
>>> +
>>>   
>>>   /* intel_opregion.c */
>>>   #ifdef CONFIG_ACPI
>>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>>> b/drivers/gpu/drm/i915/intel_bios.c
>>> index 83667e8..32e1def 100644
>>> --- a/drivers/gpu/drm/i915/intel_bios.c
>>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>>> @@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct 
>>> drm_i915_private *dev_priv,
>>>   
>>> return false;
>>>   }
>>> +
>>> +/**
>>> + * intel_bios_is_lspcon_present - if LSPCON is attached on %port
>>> + * @dev_priv:  i915 device instance
>>> + * @port:  port to check
>>> + *
>>> + * Return true if LSPCON is present on this port
>>> + */
>>> +bool
>>> +intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
>>> +   enum port port)
>>> +{
>>> +   int i;
>>> 

Re: [Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

[Joonas Lahtinen]

On pe, 2016-10-14 at 14:44 +0100, Chris Wilson wrote:
> If the kernel is old, more than a few releases old, chances are that the
> user is using an old kernel for a good reason, despite there being GPU
> hangs. After 180days since driver release stop suggesting that they
> should send those reports upstream.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

Maybe we could even explicitly state that bugs should be reported to
the distro bugzilla because of running an old kernel?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> Current DRM layer functions don't parse aspect ratio information
> while converting a user mode->kernel mode or vice versa. This
> causes modeset to pick mode with wrong aspect ratio, eventually
> causing failures in HDMI compliance test cases, due to wrong VIC.
> 
> This patch adds aspect ratio information in DRM's mode conversion
> and mode comparision functions, to make sure kernel picks mode
> with right aspect ratio (as per the VIC).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lin, Jia 
> Signed-off-by: Akashdeep Sharma 
> Reviewed-by: Jim Bride 
> Reviewed-by: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> 
> V2: Addressed review comments from Sean:
> - Fix spellings/typo
> - No need to handle aspect ratio none
> - Add a break, for default case too
> V3: Rebase
> V4: Added r-b from Jose
> ---
>  drivers/gpu/drm/drm_modes.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 53f07ac..fde927a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
> + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->picture_aspect_ratio) {
> + case HDMI_PICTURE_ASPECT_4_3:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> + break;
> + case HDMI_PICTURE_ASPECT_16_9:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> + break;
> + case HDMI_PICTURE_ASPECT_RESERVED:
> + default:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> + break;
> + }
> +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  }
> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  
> + /* Clearing picture aspect ratio bits from out flags */
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.
Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.

And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915. It's looking like we might need a new
propetty value to differentiate between "auto" and "none" for real.

> +
>   out->status = drm_mode_validate_basic(out);
>   if (out->status != MODE_OK)
>   goto out;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Rearrange i915_wait_request() accounting with callers

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Our low-level wait routine has evolved from our generic wait interface
> that handled unlocked, RPS boosting, waits with time tracking. If we
> push our GEM fence tracking to use reservation_objects (required for
> handling multiple timelines), we lose the ability to pass the required
> information down to i915_wait_request(). However, if we push the extra
> functionality from i915_wait_request() to the individual callsites
> (i915_gem_object_wait_rendering and i915_gem_wait_ioctl) that make use
> of those extras, we can both simplify our low level wait and prepare for
> extending the GEM interface for use of reservation_objects.
> 
> Signed-off-by: Chris Wilson 

No changelog so I assume only whitespace fixes were made, and hopefully
not to the worse.

So;

Reviewed-by: Joonas Lahtinen 

If you split the i915_gem_wait_for_error removal to own patch with
"Fixes:" you can add my R-b there too.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Daniel Vetter]

On Mon, Oct 17, 2016 at 05:34:36PM +0530, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
>   supported for HDMI 2.0 4k modes.
> 
> Adding aspect ratio support in DRM layer:
> - The CEA videmodes contain aspect ratio information, which we
>   parse when we read the modes from EDID. But while transforming
>   user_mode to kernel_mode or viceversa, DRM layer lose this
>   information.
> - HDMI compliance testing for CEA modes, expects the AVI info frames
>   to contain exact VIC no for the 'video mode under test'. Now CEA
>   modes have different VIC for same modes but different aspect ratio
>   for example:
> VIC 2 = 720x480@60 4:3
> VIC 3 = 720x480@60 16:9
>   In this way, lack of aspect ratio information, can cause wrong VIC
>   no in AVI IF, causing HDMI complaince test to fail.
> - This patch set adds code, which embeds the aspect ratio information
>   also in DRM video mode flags, and uses it while comparing two modes.
> 
> Adding new aspect ratios for HDMI 2.0
> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>   modes.
> - 64:27
> - 256:135
> Last two patches in the series, adds code to handle these new
> aspect ratios.
> 
> V2: Fixed review comments from Sean, Emil, Daniel
> V3: Fixed review comments from Jim Bride, got r-b for all patches
> V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3
> 
> Shashank Sharma (4):
>   drm: add picture aspect ratio flags
>   drm: Add aspect ratio parsing in DRM layer
>   video: Add new aspect ratios for HDMI 2.0
>   drm: Add and handle new aspect ratios in DRM layer

Applied to drm-misc, thanks. I guess you'll follow up with i915 patches to
remove the picture aspect ratio for overrides eventually?

Thanks, Daniel

> 
>  drivers/gpu/drm/drm_modes.c | 43 +++
>  drivers/video/hdmi.c|  4 
>  include/linux/hdmi.h|  2 ++
>  include/uapi/drm/drm_mode.h | 24 +++-
>  4 files changed, 68 insertions(+), 5 deletions(-)
> 
> -- 
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 06/41] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:17 +0100, Chris Wilson wrote:
> We will need to wait on DMA completion (as signaled via struct fence)
> before executing our i915_gem_request. Therefore we want to expose a
> method for adding the await on the fence itself to the request.
> 
> v2: Add a comment detailing a failure to handle a signal-on-any
> fence-array.
> 
> Signed-off-by: Chris Wilson 

With the magic removed (10*HZ), this was already;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for mm/vmalloc: Replace opencoded 4-level page walkers

[Patchwork]

== Series Details ==

Series: mm/vmalloc: Replace opencoded 4-level page walkers
URL   : https://patchwork.freedesktop.org/series/13822/
State : warning

== Summary ==

Series 13822v1 mm/vmalloc: Replace opencoded 4-level page walkers
https://patchwork.freedesktop.org/api/1.0/series/13822/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
dmesg-warn -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup create-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup create-fd-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup basic-threads:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
 

Re: [Intel-gfx] [PATCH 25/41] drm/i915: Move GEM activity tracking into a common struct reservation_object

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> In preparation to support many distinct timelines, we need to expand the
> activity tracking on the GEM object to handle more than just a request
> per engine. We already use the struct reservation_object on the dma-buf
> to handle many fence contexts, so integrating that into the GEM object
> itself is the preferred solution. (For example, we can now share the same
> reservation_object between every consumer/producer using this buffer and
> skip the manual import/export via dma-buf.)
> 
> v2: Reimplement busy-ioctl (by walking the reservation object), postpone
> the ABI change for another day. Similarly use the reservation object to
> find the last_write request (if active and from i915) for choosing
> display CS flips.
> 
> Caveats:
> 
>  * busy-ioctl: busy-ioctl only reports on the native fences, it will not
> warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is
> being rendered to by external fences. It also will not report the same
> busy state as wait-ioctl (or polling on the dma-buf) in the same
> circumstances. On the plus side, it does retain reporting of which
> *i915* engines are engaged with this object.
> 
>  * non-blocking atomic modesets take a step backwards as the wait for
> render completion blocks the ioctl. This is fixed in a subsequent
> patch to use a fence instead for awaiting on the rendering, see
> "drm/i915: Restore nonblocking awaits for modesetting"
> 
>  * dynamic array manipulation for shared-fences in reservation is slower
> than the previous lockless static assignment (e.g. gem_exec_lut_handle
> runtime on ivb goes from 42s to 66s), mainly due to atomic operations.
> 
>  * loss of object-level retirement callbacks, emulated by VMA retirement
> tracking.
> 
>  * minor loss of object-level last activity information from debugfs,
> could be replaced with per-vma information if desired
> 
> Signed-off-by: Chris Wilson 

This was already:

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 38/41] drm/i915: Defer setting of global seqno on request to submission

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Defer the assignment of the global seqno on a request to its submission.
> In the next patch, we will only allocate the global seqno at that time,
> here we are just enabling the wait-for-submission before wait-for-seqno
> paths.
> 
> Signed-off-by: Chris Wilson 

This was already;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 32/41] drm/i915: Rename ->emit_request to ->emit_breadcrumb

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Now that the emission of the request tail and its submission to hardware
> are two separate steps, engine->emit_request() is confusing.
> engine->emit_request() is called to emit the breadcrumb commands for the
> request into the ring, name it such (engine->emit_breadcrumb).
> 
> Signed-off-by: Chris Wilson 

Oh my, a patch does precisely what it says in the commit message,
nothing else, nothing less!

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for : Picture aspect ratio support in DRM layer (rev2)

[Saarinen, Jani]

> == Series Details ==
> 
> Series: : Picture aspect ratio support in DRM layer (rev2)
> URL   : https://patchwork.freedesktop.org/series/10587/
> State : warning
> 
> == Summary ==
> 
> Series 10587v2 : Picture aspect ratio support in DRM layer
> https://patchwork.freedesktop.org/api/1.0/series/10587/revisions/2/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup bad-source:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
Same old https://bugs.freedesktop.org/show_bug.cgi?id=98251 to all

 [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
underrun
 [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
underrun

> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-skl-6260u)
> skip   -> PASS   (fi-skl-6770hq)
> pass   -> SKIP   (fi-hsw-4770)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:181  dwarn:3   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2734/
> 
> 15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 2016y-10m-
> 16d-23h-15m-00s UTC integration manifest 5c0848b drm: Add and handle
> new aspect ratios in DRM layer
> dca13e5 video: Add new aspect ratios for HDMI 2.0
> 69f5805 drm: Add aspect ratio parsing in DRM layer b38c91c drm: add picture
> aspect ratio flags
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



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

[Intel-gfx] [PATCH v4 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
V4: Added r-b from Jose.
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too
V3: Rebase
V4: Added r-b from Jose
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches
V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h | 24 +++-
 4 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v4 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Reviewed-by: Jose Abreu 
Acked-by: Tomi Valkeinen 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
V4: Added r-b from Jose, Ack by Tomi
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v4 1/4] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
Reviewed-by: Jim Bride 
Reviewed-by: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
V3: Added r-b by Jose
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..5c142b1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,19 @@ extern "C" {
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
 
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 22:19) */
+#define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PIC_AR_NONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE<<19)
+#define  DRM_MODE_FLAG_PIC_AR_4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
+#define  DRM_MODE_FLAG_PIC_AR_16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -92,11 +105,6 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for : Picture aspect ratio support in DRM layer (rev2)

[Patchwork]

== Series Details ==

Series: : Picture aspect ratio support in DRM layer (rev2)
URL   : https://patchwork.freedesktop.org/series/10587/
State : warning

== Summary ==

Series 10587v2 : Picture aspect ratio support in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/10587/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup bad-source:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-a-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> DMESG-WARN (fi-ilk-650)
Test vgem_basic:
Subgroup unload:
pass   -> SKIP   (fi-skl-6260u)
skip   -> PASS   (fi-skl-6770hq)
pass   -> SKIP   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:181  dwarn:3   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2734/

15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 
2016y-10m-16d-23h-15m-00s UTC integration manifest
5c0848b drm: Add and handle new aspect ratios in DRM layer
dca13e5 video: Add new aspect ratios for HDMI 2.0
69f5805 drm: Add aspect ratio parsing in DRM layer
b38c91c drm: add picture aspect ratio flags

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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:38:01PM +0300, Tomi Sarvela wrote:
> On Monday, 17 October 2016 14:33:28 EEST Ville Syrjälä wrote:
> > On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> > > == Series Details ==
> > > 
> > > Series: drm/i915: Suppress underrun reporting around DP link retraining
> > > URL   : https://patchwork.freedesktop.org/series/13805/
> > > State : warning
> > 
> > OK, but...
> > 
> > > == Summary ==
> > > 
> > > Series 13805v1 drm/i915: Suppress underrun reporting around DP link
> > > retraining
> > > https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/> 
> > > 
> > > Test vgem_basic:
> > > Subgroup unload:
> > > pass   -> SKIP   (fi-hsw-4770)
> > 
> > ... where is the warn here?
> 
> This was added to comparison code because I was asked to:
> 
> # pass -> SKIP
> if testresult < 1 and (lastres == 'pass' and res == 
> 'skip'):
> testresult = 1
> 
> Unintuitive, but there you go.

OK. Well, this test seems to skip<->pass quite a lot, so I'll put it
down as already busted somehow.

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

Re: [Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Jose Abreu]

Hi Shashank,


On 17-10-2016 12:32, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
>   supported for HDMI 2.0 4k modes.
>
> Adding aspect ratio support in DRM layer:
> - The CEA videmodes contain aspect ratio information, which we
>   parse when we read the modes from EDID. But while transforming
>   user_mode to kernel_mode or viceversa, DRM layer lose this
>   information.
> - HDMI compliance testing for CEA modes, expects the AVI info frames
>   to contain exact VIC no for the 'video mode under test'. Now CEA
>   modes have different VIC for same modes but different aspect ratio
>   for example:
> VIC 2 = 720x480@60 4:3
> VIC 3 = 720x480@60 16:9
>   In this way, lack of aspect ratio information, can cause wrong VIC
>   no in AVI IF, causing HDMI complaince test to fail.
> - This patch set adds code, which embeds the aspect ratio information
>   also in DRM video mode flags, and uses it while comparing two modes.
>
> Adding new aspect ratios for HDMI 2.0
> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>   modes.
> - 64:27
> - 256:135
> Last two patches in the series, adds code to handle these new
> aspect ratios.
>
> V2: Fixed review comments from Sean, Emil, Daniel
> V3: Fixed review comments from Jim Bride, got r-b for all patches
>
> Shashank Sharma (4):
>   drm: add picture aspect ratio flags
>   drm: Add aspect ratio parsing in DRM layer
>   video: Add new aspect ratios for HDMI 2.0
>   drm: Add and handle new aspect ratios in DRM layer

I am using the previous version of these patches, the
functionality remains the same so you can add my reviewed-by for
the whole series if you want. Are you still planning in sending
the patches for the new VIC's introduced in CEA-861-F?

>
>  drivers/gpu/drm/drm_modes.c | 43 +++
>  drivers/video/hdmi.c|  4 
>  include/linux/hdmi.h|  2 ++
>  include/uapi/drm/drm_mode.h | 24 +++-
>  4 files changed, 68 insertions(+), 5 deletions(-)
>

Best regards,
Jose Miguel Abreu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Tomi Sarvela]

On Monday, 17 October 2016 14:33:28 EEST Ville Syrjälä wrote:
> On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Suppress underrun reporting around DP link retraining
> > URL   : https://patchwork.freedesktop.org/series/13805/
> > State : warning
> 
> OK, but...
> 
> > == Summary ==
> > 
> > Series 13805v1 drm/i915: Suppress underrun reporting around DP link
> > retraining
> > https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/> 
> > 
> > Test vgem_basic:
> > Subgroup unload:
> > pass   -> SKIP   (fi-hsw-4770)
> 
> ... where is the warn here?

This was added to comparison code because I was asked to:

# pass -> SKIP
if testresult < 1 and (lastres == 'pass' and res == 'skip'):
testresult = 1

Unintuitive, but there you go.

Tomi

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

Re: [Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank

On 10/17/2016 5:01 PM, Jose Abreu wrote:

Hi Shashank,


On 17-10-2016 12:32, Shashank Sharma wrote:

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
   supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
   parse when we read the modes from EDID. But while transforming
   user_mode to kernel_mode or viceversa, DRM layer lose this
   information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
   to contain exact VIC no for the 'video mode under test'. Now CEA
   modes have different VIC for same modes but different aspect ratio
   for example:
 VIC 2 = 720x480@60 4:3
 VIC 3 = 720x480@60 16:9
   In this way, lack of aspect ratio information, can cause wrong VIC
   no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
   also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
   modes.
 - 64:27
 - 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches

Shashank Sharma (4):
   drm: add picture aspect ratio flags
   drm: Add aspect ratio parsing in DRM layer
   video: Add new aspect ratios for HDMI 2.0
   drm: Add and handle new aspect ratios in DRM layer

I am using the previous version of these patches, the
functionality remains the same so you can add my reviewed-by for
the whole series if you want.

Thanks Joes. I will add a V4 with your r-b.

Are you still planning in sending
the patches for the new VIC's introduced in CEA-861-F?

Yes, the very next step is the patch with new VICs.

Regards
Shashank

  drivers/gpu/drm/drm_modes.c | 43 +++
  drivers/video/hdmi.c|  4 
  include/linux/hdmi.h|  2 ++
  include/uapi/drm/drm_mode.h | 24 +++-
  4 files changed, 68 insertions(+), 5 deletions(-)


Best regards,
Jose Miguel Abreu


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

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Ville Syrjälä]

On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Suppress underrun reporting around DP link retraining
> URL   : https://patchwork.freedesktop.org/series/13805/
> State : warning

OK, but...

> 
> == Summary ==
> 
> Series 13805v1 drm/i915: Suppress underrun reporting around DP link retraining
> https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-skl-6700k)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-c:
> incomplete -> PASS   (fi-skl-6700k)
> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-hsw-4770)

... where is the warn here?

> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
> fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2727/
> 
> 38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
> 2016y-10m-14d-16h-23m-48s UTC integration manifest
> 171418c drm/i915: Suppress underruns during DP link retraining
> 2a576f6 drm/i915: Extract intel_crtc_pch_transcoder()

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

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for dozen iterations to maximize coverage

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 423 +
 2 files changed, 424 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..0cb7552
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,423 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define SIZE 128
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   bool user_seed;
+   int seed;
+   bool user_logfile;
+   char logfile[SIZE];
+} opt = {
+   .user_seed = false,
+   .seed = 1,
+   .user_logfile = false,
+   .logfile = "kms_plane_multiple.log",
+};
+
+
+static int logwrite(const char *testname)
+{
+   time_t curr_time;
+   FILE *fid;
+   char *time_str;
+
+   fid = fopen(opt.logfile, "a");
+
+   if (fid == NULL) {
+   igt_debug("Could not open file %s\n", opt.logfile);
+   return -1;
+   }
+
+   curr_time = time(NULL);
+
+   time_str = ctime(_time);
+   time_str[strlen(time_str)-1] = '\0';
+
+   fprintf(fid, "%s: kms_plane_multiple --run-subtest %s --seed %d\n",
+   time_str, testname, opt.seed);
+
+   fclose(fid);
+
+   return 0;
+}
+
+/*
+ * Common code across all tests, acting on data_t
+ */
+static void test_init(data_t *data, enum pipe pipe)
+{
+   data->pipe_crc = igt_pipe_crc_new(pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
+}
+
+static void test_fini(data_t *data, igt_output_t *output, int max_planes)
+{
+   igt_plane_set_fb(data->plane[IGT_PLANE_PRIMARY], NULL);
+
+   for (int i = IGT_PLANE_2; i <= max_planes; i++)
+   igt_plane_set_fb(data->plane[i], NULL);
+
+   /* reset the constraint on the pipe */
+   igt_output_set_pipe(output, PIPE_ANY);
+
+   igt_pipe_crc_free(data->pipe_crc);
+}
+
+static bool test_is_atomic(const char *testname)
+{
+   if (strncmp(testname, 

Re: [Intel-gfx] [PATCH 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Chris Wilson]

On Mon, Oct 17, 2016 at 11:55:54AM +0100, Tvrtko Ursulin wrote:
> On 14/10/2016 13:18, Chris Wilson wrote:
> >  static void
> >-i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
> >+i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj,
> >+  struct sg_table *pages)
> >  {
> > struct sgt_iter sgt_iter;
> > struct page *page;
> >-int ret;
> >-GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
> >-
> >-ret = i915_gem_object_set_to_cpu_domain(obj, true);
> >-if (WARN_ON(ret)) {
> >-/* In the event of a disaster, abandon all caches and
> >- * hope for the best.
> >- */
> >-i915_gem_clflush_object(obj, true);
> >-obj->base.read_domains = obj->base.write_domain = 
> >I915_GEM_DOMAIN_CPU;
> >-}
> >+__i915_gem_object_release_shmem(obj);
> 
> Waiting for the object to become inactive is now gone. It did not
> spot that that changed with this patch. Did it?

There's no wait here. We have BUG_ONs today (that remain in place)
to catch trying to free pages that are in use by the GPU. This is just a
change of domains (and I wanted to keep the set-to-cpu-domain asserts,
and avoid the other side effects).
 
> >  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> >  {
> >-struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> >-const struct drm_i915_gem_object_ops *ops = obj->ops;
> >-int ret;
> >+int err;
> > lockdep_assert_held(>base.dev->struct_mutex);
> > if (obj->mm.pages)
> > return 0;
> >-if (obj->mm.madv != I915_MADV_WILLNEED) {
> >-DRM_DEBUG("Attempting to obtain a purgeable object\n");
> >-__i915_gem_object_unpin_pages(obj);
> >-return -EFAULT;
> >-}
> >-
> >-ret = ops->get_pages(obj);
> >-if (ret) {
> >+err = i915_gem_object_get_pages(obj);
> >+if (err)
> > __i915_gem_object_unpin_pages(obj);
> >-return ret;
> >-}
> >-list_add_tail(>global_list, _priv->mm.unbound_list);
> 
> Objects will no longer appear on the unbound list when they have
> backing store?

They still do. We don't hold the struct_mutex here, so we defer the
global list tracking to the domain management which is slightly later. 

However, there is still a window of opportunity where we have pages
pinned for our use but not yet visible to the shrinker. A bit of
rejigging should be mean we only need to move the unbound upon
pages_pin_count==0 and it will require a spinlock, but that make
actually work out to be less code. But it won't yet reduce the
struct_mutex hold time in the shrinker, so I'm not seeing the upside
yet.

> >+static bool unsafe_drop_pages(struct drm_i915_gem_object *obj)
> >+{
> >+if (i915_gem_object_unbind(obj) == 0)
> >+__i915_gem_object_put_pages(obj);
> >+return !obj->mm.pages;
> >+}
> 
> Can we have some comments with this function?

It may or may not result in the pages being freed, and it may or may
result in the object being unreferenced. There used to be a function
called drop_pages (which the same caveats) that got misused so I removed
it and wanted to be sure that they didn't repeat their mistakes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

On Wed, 2016-10-12 at 14:54 +0200, Maarten Lankhorst wrote:
> Op 07-10-16 om 13:45 schreef Mika Kahola:
> > 
> > This is a testcase with multiple planes. The idea here is the
> > following
> > 
> >  - draw a uniform frame with blue color
> >  - grab crc for reference
> >  - put planes randomly on top with the same blue color
> >  - punch holes with black color into the primary framebuffer
> >  - ideally the planes should cover these holes so that the output
> > is the
> >    identical to reference crc
> >  - composite all with one ioctl call
> >  - grab crc and verify that the reference crc is equal
> >  - repeat this for dozen iterations to maximize coverage
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  tests/Makefile.sources |   1 +
> >  tests/kms_plane_multiple.c | 332
> > +
> >  2 files changed, 333 insertions(+)
> >  create mode 100644 tests/kms_plane_multiple.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 598ec6f..aed0f3a 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -105,6 +105,7 @@ TESTS_progs_M = \
> >     kms_pipe_color \
> >     kms_pipe_crc_basic \
> >     kms_plane \
> > +   kms_plane_multiple \
> >     kms_properties \
> >     kms_psr_sink_crc \
> >     kms_render \
> > diff --git a/tests/kms_plane_multiple.c
> > b/tests/kms_plane_multiple.c
> > new file mode 100644
> > index 000..153d6d1
> > --- /dev/null
> > +++ b/tests/kms_plane_multiple.c
> > @@ -0,0 +1,332 @@
> > +/*
> > + * Copyright © 2016 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice
> > (including the next
> > + * paragraph) shall be included in all copies or substantial
> > portions of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#include "igt.h"
> > +#include "drmtest.h"
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SIZE 128
> > +
> > +typedef struct {
> > +   float red;
> > +   float green;
> > +   float blue;
> > +} color_t;
> > +
> > +typedef struct {
> > +   int drm_fd;
> > +   igt_display_t display;
> > +   igt_pipe_crc_t *pipe_crc;
> > +   igt_plane_t *primary;
> > +   igt_plane_t *sprite[IGT_MAX_PLANES-1];
> > +   struct igt_fb primary_fb;
> > +   struct igt_fb sprite_fb[IGT_MAX_PLANES-1];
> Single array, instead of primary/sprite separate? See also below for
> index change..
Indeed, it does look cleaner that way.
> > 
> > +} data_t;
> > +
> > +typedef struct {
> > +   data_t *data;
> > +   igt_crc_t reference_crc;
> > +} test_position_t;
> > +
> > +/*
> > + * Common code across all tests, acting on data_t
> > + */
> > +static void test_init(data_t *data, enum pipe pipe)
> > +{
> > +   data->pipe_crc = igt_pipe_crc_new(pipe,
> > INTEL_PIPE_CRC_SOURCE_AUTO);
> > +}
> > +
> > +static void test_fini(data_t *data, igt_output_t *output, int
> > nplanes)
> > +{
> > +   igt_plane_set_fb(data->primary, NULL);
> > +
> > +   for (int i = 0; i < nplanes; i++)
> > +   igt_plane_set_fb(data->sprite[i], NULL);
> > +
> > +   /* reset the constraint on the pipe */
> > +   igt_output_set_pipe(output, PIPE_ANY);
> > +
> > +   igt_pipe_crc_free(data->pipe_crc);
> > +}
> > +
> > +static void
> > +test_grab_crc(data_t *data, igt_output_t *output, enum pipe pipe,
> > +     color_t *color, uint64_t tiling, int commit,
> > +     igt_crc_t *crc /* out */)
> > +{
> > +   struct igt_fb fb;
> > +   drmModeModeInfo *mode;
> > +   igt_plane_t *primary;
> > +
> > +   igt_output_set_pipe(output, pipe);
> > +
> > +   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> > +
> > +   mode = igt_output_get_mode(output);
> > +
> > +   igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
> > >vdisplay,
> > +   DRM_FORMAT_XRGB,
> > +   LOCAL_DRM_FORMAT_MOD_NONE,
> > +   color->red, 

[Intel-gfx] [PATCH v3 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 1/4] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..5c142b1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,19 @@ extern "C" {
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
 
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 22:19) */
+#define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PIC_AR_NONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE<<19)
+#define  DRM_MODE_FLAG_PIC_AR_4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
+#define  DRM_MODE_FLAG_PIC_AR_16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -92,11 +105,6 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too

V3: Rebase
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

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

[Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h | 24 +++-
 4 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v3 0/4] Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Please ignore this series, I mixed up one patch from LSPCON in here. 
Will send the right series in few minutes. 

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Monday, October 17, 2016 4:52 PM
To: dri-de...@lists.freedesktop.org; jim.br...@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel ; 
Sharma, Shashank 
Subject: [PATCH v3 0/4] Picture aspect ratio support in DRM layer

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel

V3: Fixed review comment from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm/i915: Add lspcon resume function
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +
 drivers/gpu/drm/i915/intel_dp.c |  7 +-
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_lspcon.c |  8 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h |  6 ++
 7 files changed, 70 insertions(+), 1 deletion(-)

--
1.9.1

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

[Intel-gfx] [PATCH v3 0/4] Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel

V3: Fixed review comment from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm/i915: Add lspcon resume function
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +
 drivers/gpu/drm/i915/intel_dp.c |  7 +-
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_lspcon.c |  8 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h |  6 ++
 7 files changed, 70 insertions(+), 1 deletion(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH v3 1/4] drm/i915: Add lspcon resume function

[Shashank Sharma]

As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)

This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.

V2: Address review comments from Imre
- move lspcon_resume call to encoder->reset()
- use early returns

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_lspcon.c | 8 
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61..25f4060 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4755,11 +4755,16 @@ static void intel_edp_panel_vdd_sanitize(struct 
intel_dp *intel_dp)
 void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+   struct intel_lspcon *lspcon = _dig_port->lspcon;
+   struct intel_dp *intel_dp = _dig_port->dp;
 
if (!HAS_DDI(dev_priv))
intel_dp->DP = I915_READ(intel_dp->output_reg);
 
+   if (IS_GEN9(dev_priv) && lspcon->active)
+   lspcon_resume(lspcon);
+
if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cde05ff..ea43512 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1856,4 +1856,5 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
+void lspcon_resume(struct intel_lspcon *lspcon);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 628ae6fb..d606f1a 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -89,6 +89,14 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }
 
+void lspcon_resume(struct intel_lspcon *lspcon)
+{
+   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
+   DRM_ERROR("LSPCON resume failed\n");
+   else
+   DRM_DEBUG_KMS("LSPCON resume success\n");
+}
+
 bool lspcon_init(struct intel_digital_port *intel_dig_port)
 {
struct intel_dp *dp = _dig_port->dp;
-- 
1.9.1

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