- Oct 10, 2016
-
-
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:
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-5-git-send-email-paulo.r.zanoni@intel.com (cherry picked from commit 0727e40a ) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
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:
Lyude <cpaul@redhat.com> Reviewed-by:
-
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 (cherry picked from commit 4c0b8a8b ) Signed-off-by:
-
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 <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-2-chris@chris-wilson.co.uk (cherry picked from commit 6a800eab ) 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 (cherry picked from commit f2a91d1a ) Signed-off-by:
-
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:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473847453-4771-1-git-send-email-imre.deak@intel.com Reviewed-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+ 16e1203d 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> Cc: <stable@vger.kernel.org> Reviewed-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
Just some misc bug fixes for 4.9. * 'drm-next-4.9' of git://people.freedesktop.org/~agd5f/linux: drm/amdgpu: revert "use more than 64KB fragment size if possible" drm/amdgpu: warn if dp aux is still attached on free drm/amdgpu/dce11: add missing drm_mode_config_cleanup call drm/amdgpu: also track late init state drm/amdgpu/virtual_dce: adjust config ifdef drm/amdgpu/vce: add support for hw config packet (v2) drm/amdgpu: clean up to set fw_offset as 0 twice drm/amdgpu: remove DRM_AMD_POWERPLAY drm/radeon: Prevent races on pre DCE4 between flip submission and completion. drm/radeon: Slightly more robust flip completion handling for < DCE-4
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Another attempt, this time rebased and without the pipe crc patches: - display_info cleanups from Ville - make prime/gem lookups faster with rbtrees (Chris) - misc stuff all over * tag 'topic/drm-misc-2016-10-05' of git://anongit.freedesktop.org/drm-intel: drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it drm/bridge: analogix_dp: Add analogix_dp_psr_supported drm/fb-helper: add DRM_FB_HELPER_DEFAULT_OPS for fb_ops drm: Document caveats around atomic event handling uapi: add missing install of sync_file.h drm: Simplify drm_printk to reduce object size quite a bit drm/i915: Account for sink max TMDS clock when checking the port clock drm/i915: Replace a bunch of connector->base.display_info with a local variable drm/edid: Move dvi_dual/max_tmds_clock parsing out from drm_edid_to_eld() drm/edid: Clear the old cea_rev when there's no CEA extension in the new EDID drm/edid: Reduce the number of times we parse the CEA extension block drm/edid: Don't pass around drm_display_info needlessly drm/edid: Move dvi_dual/max_tmds_clock to drm_display_info drm/edid: Make max_tmds_clock kHz instead of MHz drm/edid: Clear old dvi_dual/max_tmds_clock before parsing the new EDID drm/edid: Clear old audio latency values before parsing the new EDID drm: Convert prime dma-buf <-> handle to rbtree drm/mediatek: mark symbols static where possible drm/rockchip: mark symbols static where possible drm/rockchip: add missing header dependencies
-
https://github.com/anholt/linuxDave Airlie authored
This pull request brings in several fixes for drm-next, mostly for HDMI. * tag 'drm-vc4-next-2016-10-06' of https://github.com/anholt/linux: drm/vc4: Add support for double-clocked modes. drm/vc4: Set up the AVI and SPD infoframes. drm/vc4: Fix support for interlaced modes on HDMI. drm/vc4: Increase timeout for HDMI_SCHEDULER_CONTROL changes. drm/vc4: Fall back to using an EDID probe in the absence of a GPIO. drm/vc4: Enable limited range RGB output on HDMI with CEA modes. drm/vc4: Fix races when the CS reads from render targets. drm/vc4: cleanup with list_first_entry_or_null()
-
- Oct 07, 2016
-
-
Eric Anholt authored
Now that we have infoframes to report the pixel repeat flag, we can start using it. Fixes locking the 720x480i and 720x576i modes on my Dell 2408WFP. Like the 1920x1080i case, they don't fit properly on the screen, though. Signed-off-by:Eric Anholt <eric@anholt.net>
-
Eric Anholt authored
Fixes a purple bar on the left side of the screen with my Dell 2408WFP. It will also be required for supporting the double-clocked video modes. Signed-off-by: -
Eric Anholt authored
We really do need to be using the halved V fields. I had been confused by the code I was using as a reference because it stored halved vsync fields but not halved vdisplay, so it looked like I only needed to divide vdisplay by 2. This reverts part of Mario's timestamping fixes that prevented CRTC_HALVE_V from applying, and instead adjusts the timestamping code to not use the crtc field in that case. Fixes locking of 1920x1080x60i on my Dell 2408WFP. There are black bars on the top and bottom, but I suspect that might be an under/overscan flags problem as opposed to video timings. Signed-off-by: -
Eric Anholt authored
Fixes occasional debug spew at boot when connected directly through HDMI, and probably confusing the HDMI state machine when we go trying to poke registers for the enable sequence too soon. Signed-off-by: -
Eric Anholt authored
On Pi0/1/2, we use an external GPIO line for hotplug detection, since the HDMI_HOTPLUG register isn't connected to anything. However, with the Pi3 the HPD GPIO line has moved off to a GPIO expander that will be tricky to get to (the firmware is constantly polling the expander using i2c0, so we'll need to coordinate with it). As a stop-gap, if we don't have a GPIO line, use an EDID probe to detect connection. Fixes HDMI display on the pi3. Signed-off-by: -
Eric Anholt authored
Fixes broken grayscale ramps on many HDMI monitors, where large areas at the ends of the ramp would all appear as black or white. Signed-off-by: -
Eric Anholt authored
With the introduction of bin/render pipelining, the previous job may not be completed when we start binning the next one. If the previous job wrote our VBO, IB, or CS textures, then the binning stage might get stale or uninitialized results. Fixes the major rendering failure in glmark2 -b terrain. Signed-off-by:
-
Masahiro Yamada authored
The combo of list_empty() check and return list_first_entry() can be replaced with list_first_entry_or_null(). Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Christian König authored
This reverts commit 1dcd32fb9c54334ec948a0f18174a748d6b14364. The block size is indeed an equal match, so this can cause performance regressions. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Grazvydas Ignotas authored
If this happens (and it recently did), we free a structure while part of it is still in use, which results in non-obvious crashes. The way it's detached is not trivial (DRM core has to call the connector .destroy callback and things must be torn down in the right order), so better detect it and warn early. Signed-off-by:
Grazvydas Ignotas <notasas@gmail.com> Signed-off-by:
-
Grazvydas Ignotas authored
All other amdgpu/dce_v* files have this call, it's only mysteriously missing from dce_v11_0.c since the file was added and causes leaks. Fixes: aaa36a97 ("drm/amdgpu: Add initial VI support") Signed-off-by:
-
Grazvydas Ignotas authored
Successful sw_init() and hw_init() states are tracked, but not late_init(). Various error paths may result in amdgpu_fini() being called before .late init is done, so late_init needs to be tracked to avoid unexpected or multiple .late_fini() calls. Signed-off-by:
-
- Oct 04, 2016
-
-
Alex Deucher authored
Include the CIK asics in the ifdef. Reviewed-By:
Emily Deng <Emily.Deng@amd.com> Signed-off-by:
-
Alex Deucher authored
This is needed for proper VCE DPM on some APUs. v2: fix the asic list Reviewed-by:
-
Huang Rui authored
Signed-off-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Alex Deucher authored
Powerplay is no longer optional after the recently cleanups Reviewed-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Reviewed-by:
-
Mario Kleiner authored
Pre DCE4 hw doesn't have reliable pageflip completion interrupts, so instead polling for flip completion is used from within the vblank irq handler to complete page flips. This causes a race if pageflip ioctl is called close to vblank: 1. pageflip ioctl queues execution of radeon_flip_work_func. 2. vblank irq fires, radeon_crtc_handle_vblank checks for flip_status == FLIP_SUBMITTED finds none, no-ops. 3. radeon_flip_work_func runs inside vblank, decides to set flip_status == FLIP_SUBMITTED and programs the flip into hw. 4. hw executes flip immediately (because in vblank), but as 2 already happened, the flip completion routine only emits the flip completion event one refresh later -> wrong vblank count/timestamp for completion and no performance gain, as instead of delaying the flip until next vblank, we now delay the next flip by 1 refresh while waiting for the delayed flip completion event. Given we often don't gain anything due to this race, but lose precision, prevent the programmed flip from executing in vblank on pre DCE4 asics to avoid this race. On pre-AVIVO hw we can't program the hw for edge-triggered flips, they always execute anywhere in vblank. Therefore delay the actual flip programming until after vblank on pre-AVIVO. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Mario Kleiner authored
Pre DCE4 hardware doesn't have (reliable) pageflip completion irqs, therefore we have to use the old polling method for flip completion handling in vblank irq. As vblank irqs fire a bit before start of vblank (when the linebuffer fifo read position reaches end of scanout), we have some fudge for flip completion handling in the last lines of active scanout. Old code assumed the threshold to be 99% of active scanout height, a ballpark estimate which worked ok. Since we know since a while how to calculate the actual threshold from linebuffer size, lets make use of it to get a more accurate threshold. This completion path is still prone to some races in corner cases, especially on pre-AVIVO hardware, so document them a bit better in the code comments. Acked-by:
-
Tomeu Vizoso authored
There's no point in enabling PSR when the panel doesn't support it. This also avoids a problem when PSR gets enabled when a CRTC is being disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR interrupt on which we wait will never arrive. This was observed on RK3288 with a panel without PSR (veyron-jaq Chromebook). It's very easy to reproduce by running the kms_rmfb test in IGT a few times. Cc: Yakir Yang <ykk@rock-chips.com> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1474639600-30090-2-git-send-email-tomeu.vizoso@collabora.com
-
Tomeu Vizoso authored
So users know whether PSR should be enabled or not. Cc: Yakir Yang <ykk@rock-chips.com> Reviewed-by:
-
Stefan Christ authored
The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default implementations for functions in struct fb_ops. A drm driver can use it like: static struct fb_ops drm_fbdev_cma_ops = { .owner = THIS_MODULE, DRM_FB_HELPER_DEFAULT_OPS, /* driver specific implementations */ }; Suggested-by:Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Stefan Christ <contact@stefanchrist.eu> Reviewed-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1475182136-15191-2-git-send-email-contact@stefanchrist.eu
-
Daniel Vetter authored
It's not that obvious how a driver can all race the atomic commit with handling the completion event. And there's unfortunately a pile of drivers with rather bad event handling which misdirect people into the wrong direction. Try to remedy this by documenting everything better. v2: Type fixes Alex spotted. v3: More typos Alex spotted. Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Alex Deucher <alexdeucher@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1475229896-6047-1-git-send-email-daniel.vetter@ffwll.ch
-
Emilio López authored
As part of the sync framework destaging, the sync_file.h header was moved, but an entry was not added on Kbuild to install it. This patch resolves this omission so that "make headers_install" installs this header. Fixes: 460bfc41 ("dma-buf/sync_file: de-stage sync_file headers") Reported-by:
Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Emilio López <emilio.lopez@collabora.co.uk> Signed-off-by:
-
Joe Perches authored
Remove function name and special " *ERROR*" from argument list $ size drivers/gpu/drm/built-in.o* (x86-32 defconfig, most drm selected) text data bss dec hex filename 5635366 182579 14328 5832273 58fe51 drivers/gpu/drm/built-in.o.new 5779552 182579 14328 5976459 5b318b drivers/gpu/drm/built-in.o.old Using "%ps", __builtin_return_address(0) is the same as "%s", __func__ except for static inlines, but it's more or less the same output. Miscellanea: o Convert args... to ##__VA_ARGS__ o The equivalent DRM_DEV_<FOO> macros are rarely used and not worth conversion Reviewed-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Ville Syrjälä authored
It's perfectly legal for the sink to support 12bpc only for some lower resolution modes, while the higher resolution modes can only be used with 8bpc. So let's take the sink's max TMDS clock into account before we go and decide that a particular mode can be used with 12bpc. Signed-off-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Reduce the eyesore with a local variable. Signed-off-by:
-
Ville Syrjälä authored
drm_edid_to_eld() is just mean to cook up the ELD for the audio driver, so having it parse non-audio related stuff seems just wrong, and potentially could lead to that information not being even filled out if the function doesn't even get called. Let's move that stuff to the place where we parse the color formats and whatnot from the CEA ext block. Signed-off-by:
-
