summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
...
| * | drm/i915: avoid rebuilding i915_gpu_error.o on version string updatesHans Holmberg2018-11-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to rebuild i915_gpu_error.o when the version string changes as the version is available in init_utsname()->release. Signed-off-by: Hans Holmberg <hans.holmberg@cnexlabs.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121095423.20760-1-hans.ml.holmberg@owltronix.com
| * | drm/i915: Show waiter's status on engine dumpChris Wilson2018-11-211-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When showing the list of waiters, include the task's status so that we can tell if they have been woken up and are waiting for the CPU, or if they are still waiting to be woken. v2: task_state_to_char() Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181121151653.24595-1-chris@chris-wilson.co.uk
| * | drm/i915: Add rotation readout for plane initial configVille Syrjälä2018-11-212-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we need to force a full plane update before userspace/fbdev have given us a proper plane state we should try to maintain the current plane state as much as possible (apart from the parts of the state we're trying to fix up with the plane update). To that end add basic readout for the plane rotation and maintain it during the initial fb takeover. Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-2-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
| * | drm/i915: Force a LUT update in intel_initial_commit()Ville Syrjälä2018-11-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we force a plane update to fix up our half populated plane state we'll also force on the pipe gamma for the plane (since we always enable pipe gamma currently). If the BIOS hasn't programmed a sensible LUT into the hardware this will cause the image to become corrupted. Typical symptoms are a purple/yellow/etc. flash when the driver loads. To avoid this let's program something sensible into the LUT when we do the plane update. In the future I plan to add proper plane gamma enable readout so this is just a temporary measure. Cc: Hans de Goede <hdegoede@redhat.com> Fixes: 516a49cc1946 ("drm/i915: Fix assert_plane() warning on bootup with external display") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
| * | drm/i915: Make CHICKEN_TRANS reg not depend on enum valueImre Deak2018-11-213-17/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the transcoder enum values to translate from transcoder to the corresponding CHICKEN_TRANS register can easily break if we add a new transcoder. Add an explicit mapping instead, by using helpers to look up the register instance either by transcoder or port (since unconveniently the registers have both port and transcoder specific bits). While at it also check for the correctness of GEN, port, transcoder. I wasn't sure if psr2_enabled can only be set for GEN9+, but that seems to be the case indeed (see setting of sink_psr2_support in intel_psr_init_dpcd()). v2 (Ville): - Make gen9_chicken_trans_reg() internal to intel_psr.c. - s/trans/cpu_transcoder/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119180021.370-1-imre.deak@intel.com
| * | drm/i915: Add code comment on assumption of pipe==transcoderImre Deak2018-11-211-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a comment to the pipe and transcoder enum definitions about our assumption in the code about enum values for pipes and transcoders with a 1:1 transcoder -> pipe mapping. v2: - Clarify more what are the assumptions about the enum values. (Ville) v3: (Lucas) - s/->/ -> / so it looks less like pointer dereferencing. - Use pipe enums as initializers in the transcoder enum definition. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-3-imre.deak@intel.com
| * | drm/i915: Make EDP PSR flags not depend on enum valuesImre Deak2018-11-212-21/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the transcoder enum values to translate from transcoder to EDP PSR flags can easily break if we add a new transcoder. So remove the dependency by using an explicit mapping. While at it also add a WARN for unexpected trancoders. v2: - Simplify things by defining flag shift values instead of indices. - s/trans/cpu_transcoder/ (Ville) v3: - Define flags to look like separate bits instead of the values of the same bitfield. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-2-imre.deak@intel.com
| * | drm/i915: Make pipe/transcoder offsets not depend on enum valuesImre Deak2018-11-211-14/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Depending on the transcoder enum values to translate from transcoder to pipe/transcoder register addresses can easily break if we add a new transcoder. So remove the dependency by using named initializers. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120092325.21249-1-imre.deak@intel.com
| * | drm/i915: fix spelling mistake "reserverd" -> "reserved"Alexandre Belloni2018-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Fix a spelling mistake in a comment. Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120151415.32419-1-alexandre.belloni@bootlin.com
| * | drm/i915: Downgrade unknown CSR firmware warningsLucas De Marchi2018-11-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like it was done in commit 9e180d9991dc ("drm/i915: Downgrade unknown firmware warnings") for huc and guc: downgrade CSR firmware warnings. If we have released no firmware yet for a platform, stop scaring the consumer and merely note its expected absence. By simply removing the warning and early return we hit the condition with the appropriate message. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181117004234.23437-2-lucas.demarchi@intel.com
| * | drm/i915: allow to load DMC firmware on next genLucas De Marchi2018-11-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before commit d8a5b7d79fb7 ("drm/i915/csr: keep max firmware size together with firmare name and version") it was possible to load the firmware for testing purposes via parameter. Let's use the size of the last known platform to recover that behavior. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181117004234.23437-1-lucas.demarchi@intel.com
| * | drm/i915/ilk: Fix warning when reading emon_status with no outputJosé Roberto de Souza2018-11-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When there is no output no one will hold a runtime_pm reference causing a warning when trying to read emom_status in debugfs. [22.756480] ------------[ cut here ]------------ [22.756489] RPM wakelock ref not held during HW access [22.756578] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756580] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core e1000e snd_pcm mei_me prime_numbers mei lpc_ich [22.756595] CPU: 0 PID: 1058 Comm: debugfs_test Not tainted 4.20.0-rc1-CI-Trybot_3219+ #1 [22.756597] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011 [22.756634] RIP: 0010:gen5_read32+0x16b/0x1a0 [i915] [22.756637] Code: a4 ea e0 0f 0b e9 d2 fe ff ff 80 3d a5 71 19 00 00 0f 85 d3 fe ff ff 48 c7 c7 48 d0 2d a0 c6 05 91 71 19 00 01 e8 35 a4 ea e0 <0f> 0b e9 b9 fe ff ff e8 69 c6 f2 e0 85 c0 75 92 48 c7 c2 78 d0 2d [22.756639] RSP: 0018:ffffc90000f1fd38 EFLAGS: 00010282 [22.756642] RAX: 0000000000000000 RBX: ffff8801f7ab0000 RCX: 0000000000000006 [22.756643] RDX: 0000000000000006 RSI: ffffffff8212886a RDI: ffffffff820d6d57 [22.756645] RBP: 0000000000011020 R08: 0000000043e3d1a8 R09: 0000000000000000 [22.756647] R10: ffffc90000f1fd80 R11: 0000000000000000 R12: 0000000000000001 [22.756649] R13: ffff8801f7ab0068 R14: 0000000000000001 R15: ffff88020d53d188 [22.756651] FS: 00007f2878849980(0000) GS:ffff880213a00000(0000) knlGS:0000000000000000 [22.756653] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22.756655] CR2: 00005638deedf028 CR3: 0000000203292001 CR4: 00000000000206f0 [22.756657] Call Trace: [22.756689] i915_mch_val+0x1b/0x60 [i915] [22.756721] i915_emon_status+0x45/0xd0 [i915] [22.756730] seq_read+0xdb/0x3c0 [22.756736] ? lockdep_hardirqs_off+0x94/0xd0 [22.756740] ? __slab_free+0x24e/0x510 [22.756746] full_proxy_read+0x52/0x90 [22.756752] __vfs_read+0x31/0x170 [22.756759] ? do_sys_open+0x13b/0x240 [22.756763] ? rcu_read_lock_sched_held+0x6f/0x80 [22.756766] vfs_read+0x9e/0x140 [22.756770] ksys_read+0x50/0xc0 [22.756775] do_syscall_64+0x55/0x190 [22.756781] entry_SYSCALL_64_after_hwframe+0x49/0xbe [22.756783] RIP: 0033:0x7f28781dc34e [22.756786] Code: 00 00 00 00 48 8b 15 71 8c 20 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff c3 0f 1f 40 00 8b 05 ba d0 20 00 85 c0 75 16 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5a f3 c3 0f 1f 84 00 00 00 00 00 41 54 55 49 [22.756787] RSP: 002b:00007ffd33fa0d08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [22.756790] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f28781dc34e [22.756792] RDX: 0000000000000200 RSI: 00007ffd33fa0d50 RDI: 0000000000000008 [22.756794] RBP: 00007ffd33fa0f60 R08: 0000000000000000 R09: 0000000000000020 [22.756796] R10: 0000000000000000 R11: 0000000000000246 R12: 00005638de45c2c0 [22.756797] R13: 00007ffd33fa14b0 R14: 0000000000000000 R15: 0000000000000000 [22.756806] irq event stamp: 47950 [22.756811] hardirqs last enabled at (47949): [<ffffffff810fba74>] vprintk_emit+0x124/0x320 [22.756813] hardirqs last disabled at (47950): [<ffffffff810019b0>] trace_hardirqs_off_thunk+0x1a/0x1c [22.756816] softirqs last enabled at (47518): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 [22.756820] softirqs last disabled at (47479): [<ffffffff8108df29>] irq_exit+0xa9/0xc0 [22.756858] WARNING: CPU: 0 PID: 1058 at drivers/gpu/drm/i915/intel_drv.h:2104 gen5_read32+0x16b/0x1a0 [i915] [22.756860] ---[ end trace bf56fa7d6a3cbf7a ] Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119230101.32460-1-jose.souza@intel.com
| * | drm/i915/selftests: Hold task reference to reset workerChris Wilson2018-11-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the worker may exit by itself, we need to hold a task reference to it in the parent. References: https://bugs.freedesktop.org/show_bug.cgi?id=108735 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181120120601.24083-1-chris@chris-wilson.co.uk
| * | Merge drm/drm-next into drm-intel-next-queuedJani Nikula2018-11-20401-9102/+12174
| |\ \ | | | | | | | | | | | | | | | | | | | | Pull in v4.20-rc3 via drm-next. Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | drm/i915/fixed: cosmetic cleanupJani Nikula2018-11-201-36/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clean up fixed point temp variable initialization, use the more conventional tmp name for temp variables, add empty lines before return. No functional changes. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-5-jani.nikula@intel.com
| * | | drm/i915/fixed: simplify is_fixed16_zero()Jani Nikula2018-11-201-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simply return the condition. No functional changes. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-4-jani.nikula@intel.com
| * | | drm/i915/fixed: simplify FP_16_16_MAX definitionJani Nikula2018-11-201-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No need to use a compound statement enclosed in parenthesis where a C99 compound literal will do. No functional changes. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-3-jani.nikula@intel.com
| * | | drm/i915/fixed: prefer kernel types over stdint typesJani Nikula2018-11-201-32/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While at it, conform to kernel spacing (i.e. no space) after cast. No functional changes. Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-2-jani.nikula@intel.com
| * | | drm/i915: extract fixed point math to i915_fixed.hJani Nikula2018-11-202-138/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduce bloat in one of the bigger header files. Fix some indentation while at it. No functional changes. v2: Add include guards (Joonas) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116120729.7580-1-jani.nikula@intel.com
| * | | drm/i915: Write GPU relocs harder with gen3Chris Wilson2018-11-201-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Under moderate amounts of GPU stress, we can observe on Bearlake and Pineview (later gen3 models) that we execute the following batch buffer before the write into the batch is coherent. Adding extra (tested with upto 32x) MI_FLUSH to either the invalidation, flush or both phases does not solve the incoherency issue with the relocations, but emitting the MI_STORE_DWORD_IMM twice does. So be it. Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing") Testcase: igt/gem_tiled_fence_blits # blb/pnv Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181119154153.15327-1-chris@chris-wilson.co.uk
| * | | drm/i915: Prevent machine hang from Broxton's vtd w/a and error captureChris Wilson2018-11-193-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since capturing the error state requires fiddling around with the GGTT to read arbitrary buffers and is itself run under stop_machine(), it deadlocks the machine (effectively a hard hang) when run in conjunction with Broxton's VTd workaround to serialize GGTT access. v2: Store the ERR_PTR in first_error so that the error can be reported to the user via sysfs. v3: Mention the quirk in dmesg (using info as per usual) Fixes: 0ef34ad6222a ("drm/i915: Serialize GTT/Aperture accesses on BXT") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: John Harrison <john.C.Harrison@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181102161232.17742-5-chris@chris-wilson.co.uk
| * | | drm/i915: Hide enable_gvt modparam when not compiled inJoonas Lahtinen2018-11-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hide the enable_gvt modparam in the default scenario where support has not been compiled in. Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116144447.7836-1-joonas.lahtinen@linux.intel.com
| * | | Revert "drm/i915/perf: Fix warning in documentation"Joonas Lahtinen2018-11-191-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace portion is still missing. This reverts commit 9fa6e2f7609fdbb7d6f86be86371a5719bec0376. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116135510.13807-2-joonas.lahtinen@linux.intel.com
| * | | Revert "drm/i915/perf: add a parameter to control the size of OA buffer"Joonas Lahtinen2018-11-193-69/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace portion is still missing. This reverts commit cd956bfcd0f58d20485ac0a785415f7d9327a95f. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181116135510.13807-1-joonas.lahtinen@linux.intel.com
| * | | drm/i915: Downgrade unknown firmware warningsChris Wilson2018-11-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have released no firmware yet for a platform, stop scaring the consumer and merely note its expected absence. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Petri Latvala <petri.latvala@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181009111259.20807-1-chris@chris-wilson.co.uk
| * | | drm/i915: Disable LP3 watermarks on all SNB machinesVille Syrjälä2018-11-161-1/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I have a Thinkpad X220 Tablet in my hands that is losing vblank interrupts whenever LP3 watermarks are used. If I nudge the latency value written to the WM3 register just by one in either direction the problem disappears. That to me suggests that the punit will not enter the corrsponding powersave mode (MPLL shutdown IIRC) unless the latency value in the register matches exactly what we read from SSKPD. Ie. it's not really a latency value but rather just a cookie by which the punit can identify the desired power saving state. On HSW/BDW this was changed such that we actually just write the WM level number into those bits, which makes much more sense given the observed behaviour. We could try to handle this by disallowing LP3 watermarks only when vblank interrupts are enabled but we'd first have to prove that only vblank interrupts are affected, which seems unlikely. Also we can't grab the wm mutex from the vblank enable/disable hooks because those are called with various spinlocks held. Thus we'd have to redesigne the watermark locking. So to play it safe and keep the code simple we simply disable LP3 watermarks on all SNB machines. To do that we simply zero out the latency values for watermark level 3, and we adjust the watermark computation to check for that. The behaviour now matches that of the g4x/vlv/skl wm code in the presence of a zeroed latency value. v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris) Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com
| * | | drm/i915/selftests: Workaround an issue with unused lockdep subclassChris Wilson2018-11-163-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lockdep insists that if we give a lock a subclass, it must be used. Failure to do so triggers a self-consistency check when reading lockdep_stats: [ 49.902002] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused) [ 49.902009] WARNING: CPU: 3 PID: 383 at kernel/locking/lockdep_proc.c:249 lockdep_stats_show+0x984/0xa10 [ 49.902026] Modules linked in: nls_ascii nls_cp437 vfat fat crct10dif_pclmul crc32_pclmul crc32c_intel aesni_intel aes_x86_64 crypto_simd cryptd glue_helper intel_cstate intel_uncore intel_rapl_perf intel_gtt efivars prime_numbers ahci libahci i2c_i801 video button efivarfs [last unloaded: drm_kms_helper] [ 49.902059] CPU: 3 PID: 383 Comm: cat Tainted: G U 4.20.0-rc2+ #304 [ 49.902068] Hardware name: Intel Corporation NUC7i5BNK/NUC7i5BNB, BIOS BNKBL357.86A.0052.2017.0918.1346 09/18/2017 [ 49.902079] RIP: 0010:lockdep_stats_show+0x984/0xa10 [ 49.902086] Code: 00 85 c0 0f 84 aa f8 ff ff 8b 05 77 37 e2 00 85 c0 0f 85 9c f8 ff ff 48 c7 c6 e0 57 bc 81 48 c7 c7 28 30 bb 81 e8 6b 77 fa ff <0f> 0b e9 82 f8 ff ff 48 c7 44 24 50 00 00 00 00 45 31 e4 31 db 31 [ 49.902103] RSP: 0018:ffffc90000247d58 EFLAGS: 00010292 [ 49.902110] RAX: 0000000000000044 RBX: 00000000000002f0 RCX: 0000000000000000 [ 49.902118] RDX: 0000000000000002 RSI: 0000000000000001 RDI: ffffffff810b3464 [ 49.902126] RBP: 0000000000000039 R08: 0000000000000002 R09: 0000000000000000 [ 49.902133] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000007ead [ 49.902141] R13: 0000000000000001 R14: ffff88884c021000 R15: 0000000000000097 [ 49.902150] FS: 00007fb347e66540(0000) GS:ffff88885e600000(0000) knlGS:0000000000000000 [ 49.902159] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 49.902165] CR2: 00007fb347aeb000 CR3: 00000008544bd005 CR4: 00000000001606e0 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115203851.25739-1-chris@chris-wilson.co.uk
| * | | drm/i195: spell out reverse on for_each macrosLucas De Marchi2018-11-152-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Do like it's done for list.h macros, and use "reverse" suffix rather than "rev". Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-3-lucas.demarchi@intel.com
| * | | drm/i915/icl: reverse uninit orderLucas De Marchi2018-11-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bspec 21257 says "DDIA PHY is the comp master, so it must not be un-initialized if other combo PHYs are in use". Here we are shutting down all phys, so it's not strictly required. However let's be consistent on deinitializing things in the reversed order we initialized them. v2: simplify protection for enum port being unsigned in future v3: spell out reverse rather than rev Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-2-lucas.demarchi@intel.com
| * | | drm/i915/icl: replace check for combo phyLucas De Marchi2018-11-151-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are the only places that assume ports A and B are the ones with combo phy. Let's use intel_port_is_combophy() there to make sure it checks for combo phy ports the same way everywhere. v2: define for_each_combo_port() helper to check the ports Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114011509.3667-1-lucas.demarchi@intel.com
| * | | drm/i915/bios: make the aux channel macros private to the vbt parserJani Nikula2018-11-152-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hide the aux channel macros in intel_vbt_defs.h now that their use has been abstracted in intel_bios_port_aux_ch(). Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-3-jani.nikula@intel.com
| * | | drm/i915: remove unused DDC PIN macrosJani Nikula2018-11-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Their user has vanished in the course of history. Remove. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-2-jani.nikula@intel.com
| * | | drm/i915/bios: rename intel_aux_ch() to intel_bios_port_aux_ch()Jani Nikula2018-11-155-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conform to function naming in intel_bios.c. Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181115105237.1237-1-jani.nikula@intel.com
| * | | drm/i915/hdmi: Reorder structure to match specificationClint Taylor2018-11-151-16/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reorder structure of 297, 594 N values to group Audio Sample Frequencies together to make updating from HDMI specification easier. V2: Match patch 1/2 version V3: Arrange by sample freq, then pixel clock. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1541019295-20016-1-git-send-email-clinton.a.taylor@intel.com
| * | | drm/i915: remove excess line continuation backslashesJani Nikula2018-11-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While removing .palette_offsets, I removed the commas after .trans_offsets in the macros, but failed to remove the line continuation backslashes. While at it, also remove another extra comma to be in line with the other related macros. Fixes: 74c1e826427a ("drm/i915: remove palette_offsets from device info in favor of _PICK()") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181114112130.22264-1-jani.nikula@intel.com
| * | | drm/i915: Fix plane allocation/free functionsMaarten Lankhorst2018-11-153-51/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use intel_plane_destroy_state in intel_plane_free to free the state. Also fix intel_plane_alloc() to use __drm_atomic_helper_plane_reset(), to get sane defaults from the atomic core. This is needed to get the correct alpha value and blend mode from the core, and any new default values added from new properties. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: b20815255693 ("drm/i915: Add plane alpha blending support, v2.") [mlankhorst: Update commit description to mention alpha blend support] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181113092804.13304-1-maarten.lankhorst@linux.intel.com
| * | | drm/i915: Remove special case for power well 1/MISC_IO state verificationImre Deak2018-11-141-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even though PW#1 and the MISC_IO power wells are managed by the DMC firmware (toggled dynamically if conditions allow it) from the driver's POV they are always on if the display core is initialized (always restored by DMC to the enabled state after exiting from DC5/6 for instance b/c of MMIO access). Accordingly we can just mark them as always-on and remove the special casing for them during state verification (thus enabling verification for these power wells too). Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-3-imre.deak@intel.com
| * | | drm/i915: Use proper bool bitfield initializer in power well descsImre Deak2018-11-141-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can just use a proper true/false initializer even for bitfields, which is more descriptive. Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-2-imre.deak@intel.com
| * | | drm/i915/gen9_bc: Work around DMC bug zeroing power well requestsImre Deak2018-11-141-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A DMC bug on GEN9 big core machines fails to restore the driver's request bits for the PW1 and MISC_IO power wells after a DC5/6 entry->exit sequence. As a consequence the driver's subsequent check for the enabled status of these power wells will fail, as the check considers the power wells being enabled only if both the status and request bits are set. To work around this borrow the request bits from BIOS's own request register in which DMC forces on the request bits when exiting from DC5/6. This fixes a problem reported by Ramalingam, where HDCP init failed, since PW1 reported itself as being disabled, while in reality it was enabled. Reported-by: Ramalingam C <ramalingam.c@intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-1-imre.deak@intel.com
| * | | drm/i915: Fix icl workarounds whitespacesMika Kuoppala2018-11-141-11/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Align icl workarounds whitespace with the rest of the file Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-2-mika.kuoppala@linux.intel.com
| * | | drm/i915: Deduplicate register definition for GAMW_ECO_DEV_RW_IAMika Kuoppala2018-11-142-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This got duplicated on introducing icl workarounds. Fix by using the older definition and moving the wa bit definition there. No functional changes. v3: avoid fixes tag, whitespace (Chris) References: 908ae0517363 ("drm/i915/icl: WaDisCtxReload") Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181109145333.10570-1-mika.kuoppala@linux.intel.com
| * | | drm/i915/icl: Drop spurious register read from icl_dbuf_slices_updateMika Kuoppala2018-11-141-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Register DBUF_CTL_S2 is read and it's value is not used. As there is no explanation why we should prime the hardware with read, remove it as spurious. Fixes: aa9664ffe863 ("drm/i915/icl: Enable 2nd DBuf slice only when needed") Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com
| * | | drm/i915: add ICP support to cnp_rawclk() and kill icp_rawclk()Paulo Zanoni2018-11-131-29/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I think I'm probably the one who argued in favor of having separate implementations for both PCHs, but the calculations are actually the same, the clocks are the same and the only difference is that on ICP we write the numerator to the register. I have previously suggested to kill cnp_rawclk() and keep the icp_rawclk() style, but Ville gave some good arguments that what's in this patch may be the better choice. v2: Switch numerator to 1 from 1000 and adjust calculations accordingly (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com
| * | | drm/i915: rename CNP_RAWCLK_FRAC to CNP_RAWCLK_DENPaulo Zanoni2018-11-132-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although CNP names this field "Counter Fraction", what we write to the register is really the denominator for the fractional part of the divider, not the fractional part (and the field description even says that). The ICP spec renamed the field to "Counter Fraction Denominator", which makes a lot more sense. Use the more complete ICL naming because we will merge the CNP and ICP functions into a single one, which will introduce the concept of the numerator. That will make a lot more sense when you read the "num/frac = den" calculation. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-2-paulo.r.zanoni@intel.com
| * | | drm/i915/cnp+: update to the new RAWCLK_FREQ recommendationsPaulo Zanoni2018-11-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BSpec was updated and now there's no more "subtract 1" to the Microsecond Counter Divider field. It seems this should help fixing some GMBUS issues. I'm not aware of any specific open bug that could be solved by this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-1-paulo.r.zanoni@intel.com
| * | | drm/i915: Determine DSI panel orientation from VBTVille Syrjälä2018-11-135-1/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VBT appears to have two (or possibly three) ways to indicate the panel rotation. The first is in the MIPI config block, but that apparenly usually (maybe always?) indicates 0 degrees despite the actual panel orientation. The second way to indicate this is in the general features block, which can just indicate whether 180 degress rotation is used. The third might be a separate rotation data block, but that is not at all documented so who knows what it may contain. Let's try the first two. We first try the DSI specicic VBT information, and it it doesn't look trustworthy (ie. indicates 0 degrees) we fall back to the 180 degree thing. Just to avoid too many changes in one go we shall also keep the hardware readout path for now. If this works for more than just my VLV FFRD the question becomes how many of the panel orientation quirks are now redundant? v2: Move the code into intel_dsi.c (Jani) Cc: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022142015.4026-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com>
| * | | drm/i915: Fix the VLV/CHV DSI panel orientation hw readoutVille Syrjälä2018-11-131-13/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's make sure the DSI port is actually on before we go poking at the plane register to determine which way it's rotated. Otherwise we could be looking at a plane that is feeding a HDMI port for instance. And in order to read the plane register we need the power well to be on. Make sure that is indeed the case. We'll also make sure the plane is actually enabled before we trust the rotation bit to tell us the truth. v2: s/intel_dsi/vlv_dsi/ Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181022141953.3889-1-ville.syrjala@linux.intel.com Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
| * | | drm/i915: Move skip_intermediate_wm handling into ilk_compute_intermediate_wm()Ville Syrjälä2018-11-132-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No point in cluttering the common codepaths with the skip_intermediate_wm handling. Just move it into ilk_compute_intermediate_wm() as those are the only platforms using this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108151013.24064-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
| * | | drm/i915: Account for scale factor when calculating initial phaseVille Syrjälä2018-11-133-10/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To get the initial phase correct we need to account for the scale factor as well. I forgot this initially and was mostly looking at heavily upscaled content where the minor difference between -0.5 and the proper initial phase was not readily apparent. And let's toss in a comment that tries to explain the formula a little bit. v2: The initial phase upper limit is 1.5, not 24.0! Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 0a59952b24e2 ("drm/i915: Configure SKL+ scaler initial phase correctly") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181029181820.21956-1-ville.syrjala@linux.intel.com Tested-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
| * | | drm/i915: Always write both TILEOFF and LINOFF plane registersVille Syrjälä2018-11-131-14/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reduce the clutter in the sprite update functions by writing both TILEOFF and LINOFF registers unconditionally. We already did this for primary planes so might as well do it for the sprites too. There is no harm in writing both registers. Which one gets used depends on the tilimg mode selected in the plane control registers. It might even make sense to clear the register that won't get used. That could make register dumps a little easier to parse. But I'm not sure it's worth the extra hassle. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108150955.23948-1-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
OpenPOWER on IntegriCloud