- 26 Sep, 2016 13 commits
-
-
Paulo Zanoni authored
This should affect linear and X tiled planes on really small htotal cases. It doesn't seem to be a very feasible case, but let's implement it since it's on the specification and it's better to have it and never need than not have it and realize we needed it. Reviewed-by:
Lyude <cpaul@redhat.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474578035-424-9-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
We forgot the "res_blocks += y_tile_minimum" that's described on step V of our documentation. Again, this should only affect the Y tiling cases. It looks like the relevant code was introduced in 0fda6568, but there's always the possibility that it matched our specification when it was introduced, and then the specification changed while the code stayed the same. So we can't really say this was a regression, but let's try to add a "Fixes" tag anyway to help backporting. v2: Try to add a "Fixes" tag (Maarten). Fixes: 0fda6568 ("drm/i915/skl: Update watermarks for Y tiling") Cc: stable@vger.kernel.org Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Paulo Zanoni authored
The confusing thing is that plane_blocks_per_line is listed as part of the method 2 calculation but is also used for other things. We calculated it in two different places and different ways: one inside skl_wm_method2() and the other inside skl_compute_plane_wm(). The skl_wm_method2() implementation is the one that matches the specification. With this patch we fix the skl_compute_plane_wm() calculation and just pass it as a parameter to skl_wm_method2(). We also take care to not modify the value of plane_bytes_per_line since we're going to rely on it having a correct value in later patches. This should affect the watermarks for Linear and Y-tiled. From my analysis, it looks like the two plane_blocks_per_line variables got out of sync on 0fda6568, but we can't really say that commit was a regression, it looks like just an incomplete fix. There's always the possibility that 0fda6568 matched our specification at that time, and then later the specification changed. v2: Try to add a "Fixes" tag (Maarten). Fixes: 0fda6568 ("drm/i915/skl: Update watermarks for Y tiling") Cc: stable@vger.kernel.org Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Paulo Zanoni authored
During watermarks calculations, this value is used in 3 different places. Only one of them was not using a hardcoded 4. Move the code up so everybody can benefit from the actual value. This should only help on situations with Y tiling + 90/270 rotation + 1 or 2 bpp or NV12. Cc: stable@vger.kernel.org Reviewed-by:
-
Paulo Zanoni authored
Bspec says: "The mailbox response data may not account for memory read latency. If the mailbox response data for level 0 is 0us, add 2 microseconds to the result for each valid level." This means we should only do the +2 in case wm[0] == 0, not always. So split the sanitizing implementation from the WA implementation and fix the WA implementation. v2: Add Fixes tag (Maarten). Fixes: 367294be ("drm/i915/gen9: Add 2us read latency to WM level") Cc: stable@vger.kernel.org Cc: Vandana Kannan <vandana.kannan@intel.com> Reviewed-by:
-
Paulo Zanoni authored
According to BSpec, it's the "core CPUs" that need the code, which means SKL and KBL, but not BXT. I don't have a KBL to test this patch on it. v2: Only SKL should have I915_SAGV_NOT_CONTROLLED. Cc: stable@vger.kernel.org Reviewed-by:
-
Paulo Zanoni authored
And use it to move knowledge about the SAGV-supporting platforms from the callers to the SAGV code. We'll add more platforms to intel_has_sagv(), so IMHO it makes more sense to move all this to a single function instead of patching all the callers every time we add SAGV support to a new platform. v2: Move I915_SAGV_NOT_CONTROLLED to the new function (Lyude). Cc: stable@vger.kernel.org Reviewed-by:
-
Paulo Zanoni authored
The plan is to introduce intel_has_sagv() and then use it to discover which platforms actually support it. I thought about keeping the functions with their current skl names, but found two problems: (i) skl_has_sagv() would become a very confusing name, and (ii) intel_atomic_commit_tail() doesn't seem to be calling any functions whose name start with a platform name, so the "intel_" naming scheme seems make more sense than the "firstplatorm_" naming scheme here. Cc: stable@vger.kernel.org Reviewed-by:
-
Jani Nikula authored
Pre-production hardware is not supported. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/e5433e6430dcfd941209c4d8103035ddb13d17b4.1474034059.git.jani.nikula@intel.com
-
Jani Nikula authored
Pre-production hardware is not supported. Reviewed-by:
-
Jani Nikula authored
Pre-production hardware is not supported. Reviewed-by:
-
Jani Nikula authored
Pre-production hardware is not supported. Reviewed-by:
-
Jani Nikula authored
Pre-production hardware is not supported. Reviewed-by:
-
- 22 Sep, 2016 4 commits
-
-
Paulo Zanoni authored
We never remembered to set it (so it was zero), but this was not a problem in the past due to the way handled the hardware registers. Unfortunately we changed how we set the hardware and forgot to set intel_crtc->dspaddr_offset. This started to reflect on a few kms_frontbuffer_tracking subtests that relied on page flips with CRTCs that don't point to the x:0,y:0 coordinates of the frontbuffer. After the page flip the CRTC was showing the x:0,y:0 coordinate of the frontbuffer instead of x:500,y:500. This problem is present even if we don't enable FBC or PSR. While trying to bisect it I realized that the first bad commit actually just gives me a black screen for the mentioned tests instead of showing the wrong x:0,y:0 offsets. A few commits later the black screen problem goes away and we get to the point where the code is today, but I'll consider the black screen as the first bad commit since it's the point where the IGT subtests start to fail. Fixes: 6687c906 ("drm/i915: Rewrite fb rotation GTT handling") Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-pgflip-blt Testcase: kms_frontbuffer_tracking/fbc-1p-primscrn-shrfb-evflip-blt Testcase: kms_frontbuffer_tracking/fbc-1p-shrfb-fliptrack Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471644203-23463-1-git-send-email-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
Ever since I started working on FBC I was already aware that FBC can really amplify the FIFO underrun symptoms. On systems where FIFO underruns were harmless error messages, enabling FBC would cause the underruns to give black screens. We recently tried to enable FBC on Haswell and got reports of a system that would hang after some hours of uptime, and the first bad commit was the one that enabled FBC. We also observed that this system had FIFO underrun error messages on its dmesg. Although we don't have any evidence that fixing the underruns would solve the bug and make FBC work properly on this machine, IMHO it's better if we minimize the amount of possible problems by just giving up FBC whenever we detect an underrun. v2: New version, different implementation and commit message. v3: Clarify the fact that we run from an IRQ handler (Chris). v4: Also add the underrun_detected check at can_choose() to avoid misleading dmesg messages (DK). v5: Fix Engrish, use READ_ONCE on the unlocked read (Chris). Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Lyude <cpaul@redhat.com> Cc: stevenhoneyman@gmail.com <stevenhoneyman@gmail.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473773937-19758-1-git-send-email-paulo.r.zanoni@intel.com
-
Pandiyan, Dhinakaran authored
DP MST provides the capability to send multiple video and audio streams through a single port. This requires the API's between i915 and audio drivers to distinguish between multiple audio capable displays that can be connected to a port. Currently only the port identity is shared in the APIs. This patch adds support for MST with an additional parameter 'int pipe'. The existing parameter 'port' does not change it's meaning. pipe = MST : display pipe that the stream originates from Non-MST : -1 Affected APIs: struct i915_audio_component_ops - int (*sync_audio_rate)(struct device *, int port, int rate); + int (*sync_audio_rate)(struct device *, int port, int pipe, + int rate); - int (*get_eld)(struct device *, int port, bool *enabled, - unsigned char *buf, int max_bytes); + int (*get_eld)(struct device *, int port, int pipe, + bool *enabled, unsigned char *buf, int max_bytes); struct i915_audio_component_audio_ops - void (*pin_eld_notify)(void *audio_ptr, int port); + void (*pin_eld_notify)(void *audio_ptr, int port, int pipe); This patch makes dummy changes in the audio drivers (thanks Libin) for build to succeed. The audio side drivers will send the right 'pipe' values for MST in patches that will follow. v2: Renamed the new API parameter from 'dev_id' to 'pipe'. (Jim, Ville) Included Asoc driver API compatibility changes from Jeeja. Added WARN_ON() for invalid pipe in get_saved_encoder(). (Takashi) Added comment for av_enc_map[] definition. (Takashi) v3: Fixed logic error introduced while renaming 'dev_id' as 'pipe' (Ville) Renamed get_saved_encoder() to get_saved_enc() to reduce line length v4: Rebased. Parameter check for pipe < -1 values in get_saved_enc() (Ville) Switched to for_each_pipe() in get_saved_enc() (Ville) Renamed 'pipe' to 'dev_id' in audio side code (Takashi) v5: Included a comment for the dev_id arg. (Libin) Signed-off-by:
Takashi Iwai <tiwai@suse.de> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474488168-2343-1-git-send-email-dhinakaran.pandiyan@intel.com
-
Jani Nikula authored
Fix sparse warnings: drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol 'i915_driver_load' was not declared. Should it be static? drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol 'i915_driver_unload' was not declared. Should it be static? drivers/gpu/drm/i915/i915_drv.c:2444:25: warning: symbol 'i915_pm_ops' was not declared. Should it be static? Fixes: 42f5551d ("drm/i915: Split out the PCI driver interface to i915_pci.c") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 21 Sep, 2016 11 commits
-
-
Libin Yang authored
(This patch is developed by Dave Airlie <airlied@redhat.com> originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support DP MST audio will be implemented in audio driver. v2: Rebased. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
-
Pandiyan, Dhinakaran authored
With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move audio_connector from struct intel_digital_port to struct intel_encoder. This also simplifies access to the right audio_connector from codec functions in intel_audio.c that receive intel_encoder. v2: Removed locals that are not needed anymore. v3: No code change except for minor change in context. Signed-off-by:
-
Pandiyan, Dhinakaran authored
Now that we have the port enum stored in intel_encoder, use that instead of dereferencing intel_dig_port. Saves us a few locals. struct intel_encoder variables have been renamed to be consistent and convey type information. v2: Fix incorrect 'enum port' member names - s/attached_port/port Signed-off-by:
-
Pandiyan, Dhinakaran authored
Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them (thanks danvet). v2: Renamed the port enum member from 'attached_port' to 'port' (danvet) Fixed missing initialization of port in intel_sdvo.c (danvet) v3: Fixed missing initialization of port in intel_crt.c (Ville) v4: Storing port for DVO encoders too. Signed-off-by:
-
Pandiyan, Dhinakaran authored
Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to valid values for all DVO devices at definition. v2: Changed return type, for real (Jani) Signed-off-by:
-
Chris Wilson authored
There is a disparity in the context image saved to disk and our own bookkeeping - that is we presume the RING_HEAD and RING_TAIL match our stored ce->ring->tail value. However, as we emit WA_TAIL_DWORDS into the ring but may not tell the GPU about them, the GPU may be lagging behind our bookkeeping. Upon hibernation we do not save stolen pages, presuming that their contents are volatile. This means that although we start writing into the ring at tail, the GPU starts executing from its HEAD and there may be some garbage in between and so the GPU promptly hangs upon resume. Testcase: igt/gem_exec_suspend/basic-S4 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96526Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
At the point of creating the hibernation image, the runtime power manage core is disabled - and using the rpm functions triggers a warn. i915_gem_shrink_all() tries to unbind objects, which requires device access and so tries to how an rpm reference triggering a warning: [ 44.235420] ------------[ cut here ]------------ [ 44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0 [ 44.235426] WARN_ON_ONCE(ret < 0) [ 44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci [ 44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130 [ 44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015 [ 44.235450] Workqueue: events_unbound async_run_entry_fn [ 44.235453] 0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8 [ 44.235454] 0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0 [ 44.235456] ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840 [ 44.235456] Call Trace: [ 44.235459] [<ffffffff81306c2f>] dump_stack+0x4d/0x6e [ 44.235461] [<ffffffff81056c01>] __warn+0xd1/0xf0 [ 44.235464] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30 [ 44.235465] [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60 [ 44.235468] [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0 [ 44.235469] [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0 [ 44.235471] [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360 [ 44.235473] [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90 [ 44.235475] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30 [ 44.235476] [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30 [ 44.235478] [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90 [ 44.235479] [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40 [ 44.235481] [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130 [ 44.235483] [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0 [ 44.235484] [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0 [ 44.235486] [<ffffffff81077557>] async_run_entry_fn+0x37/0x150 [ 44.235488] [<ffffffff8106f518>] process_one_work+0x148/0x3f0 [ 44.235490] [<ffffffff8106f8eb>] worker_thread+0x12b/0x490 [ 44.235491] [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0 [ 44.235492] [<ffffffff81074d09>] kthread+0xc9/0xe0 [ 44.235495] [<ffffffff816e257f>] ret_from_fork+0x1f/0x40 [ 44.235496] [<ffffffff81074c40>] ? kthread_park+0x60/0x60 [ 44.235497] ---[ end trace e438706b97c7f132 ]--- Alternatively, to actually shrink everything we have to do so slightly earlier in the hibernation process. To keep lockdep silent, we need to take struct_mutex for the shrinker even though we know that we are the only user during the freeze. Fixes: 7aab2d53 ("drm/i915: Shrink objects prior to hibernation") Signed-off-by:
-
Chris Wilson authored
Following commit 821ed7df ("drm/i915: Update reset path to fix incomplete requests") we no longer mark the context as lost on reset as we keep the requests (and contexts) alive. However, RPS remains reset and we need to restore the current state to match the in-flight requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824 Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
-
Imre Deak authored
While user space has control over the scheduling priority of its page flipping thread, the corresponding work the driver schedules for MMIO flips always runs from the generic system workqueue which has some scheduling overhead due it being CPU bound. This would hinder an application that wants more stringent guarantees over flip timing (to avoid missing a flip at the next frame count). Fix this by scheduling the work from the unbound system workqueue which provides for minimal scheduling latency. v2: - Use an unbound workqueue instead of a high-prio one. (Tvrtko, Chris) v3: - Use the system unbound wq instead of a dedicated one. (Maarten) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97775 Testcase: igt/kms_cursor_legacy CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Reviewed-by:
-
Ben Widawsky authored
v2: (Imre) - Access only subslices that are known to exist. - Reset explicitly the MCR selector to slice/sub-slice ID 0 after the readout. - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck detection too. - Take the uncore lock for the MCR-select/subslice-readout sequence. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
Consolidate the instdone logic so we can get a bit fancier. This patch also removes the duplicated print of INSTDONE[0]. v2: (Imre) - Rebased on top of hangcheck INSTDONE changes. - Move all INSTDONE registers into a single struct, store it within the engine error struct during error capturing. Signed-off-by:
-
- 20 Sep, 2016 3 commits
-
-
Imre Deak authored
Reapply the PPS register unlock workaround after GPU reset on platforms where the reset clobbers the display HW state. This at least gets rid of the related WARN during LVDS encoder enabling on PNV. Fixes: ed6143b8 ("drm/i915/lvds: Restore initial HW state during encoder enabling") Reported-by:
-
Shawn Lee authored
Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Cc: stable@vger.kernel.org # v4.4+ 32b421e7 drm/i915/backlight: setup and cache... Cc: stable@vger.kernel.org # v4.4+ Reviewed-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
-
Jani Nikula authored
This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by:
-
- 19 Sep, 2016 8 commits
-
-
Jani Nikula authored
Be a little paranoid in case the specs change or something. Reviewed-by:
-
Jani Nikula authored
Leave behind some debugging clues in case some panels don't work properly. Reviewed-by:
-
Jani Nikula authored
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add them where it feels logical. The drm panel hooks don't currently offer us more granularity anyway. Reviewed-by:
-
Jani Nikula authored
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add power on/off sequences where they feel logical and update assert/deassert reset. The drm panel hooks don't currently offer us more granularity anyway. v2: update assert/deassert reset as well (Ville) Reviewed-by:
-
Jani Nikula authored
In sequence block v3 these are gracefully skipped anyway, but add the functions so we can have some debug breadcrumbs. v2: the pmic block is 15 bytes (Ville) Reviewed-by:
-
Jani Nikula authored
Just simple breadcrumbs for now. While at it, rename the i2c skip function. Reviewed-by:
-
Jani Nikula authored
This is not interesting. They are not "missing", they are just not part of the VBT sequences for the panel. Reviewed-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 16 Sep, 2016 1 commit
-
-
Mika Kahola authored
Fix missing parameter description for DisplayPort branch device ID. This fixes warning of "No description found for parameter 'id[6]'" when creating documentation by 'make htmldocs'. Reported-by:
kbuild test robot <fengguang.wu@intel.com> References: https://lists.freedesktop.org/archives/intel-gfx/2016-September/106645.html Fixes: 266d783b ("drm: Read DP branch device id") Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
