summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-22drm/i915/gen9: Verify and enforce dc6 state writesMika Kuoppala1-2/+39
It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
2016-02-22drm/i915/gen9: Check for DC state mismatchPatrik Jakobsson3-0/+11
The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
2016-02-19drm/i915/fbc: enable FBC by default on HSW and BDWPaulo Zanoni1-1/+3
These platforms should be fine now. FBC can allow very significant power savings for screen-on idle systems, but it is worth mentioning that a lot of people won't get significant power savings by enabling this feature because they may have something else preventing the system from getting into the deepest sleep states. Examples may include a hungry wifi device or a max_performance SATA link power management policy. You can check your PC state residencies on the powertop "Idle stats" tab. I recommend trying to run "sudo powertop --auto-tune" and then seeing if the residencies improve. Oh, and in case you - the person reading this commit message - found this commit through git bisect, please do the following: - Check your dmesg and see if there are error messages mentioning underruns around the time your problem started happening. - Download intel-gpu-tools, compile it, and run: $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt Then send us the fbc.txt file, especially if you get a failure. This will really maximize your chances of getting the bug fixed quickly. - Try to find a reliable way to reproduce the problem, and tell us. - Boot with drm.debug=0xe, reproduce the problem, then send us the dmesg file. v2: Don't enable by default on SKL. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455655643-2535-1-git-send-email-paulo.r.zanoni@intel.com
2016-02-19drm/i915: drop unused i915.disable_vtd_wa module parameterJani Nikula2-5/+0
This is a manual revert of commit 7a10dfa638be26669f0987b6a21a65e6b39356b2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 1 09:33:47 2014 +0200 drm/i915: Add debug module option for VTd validation as no users have appeared. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455621493-6865-2-git-send-email-jani.nikula@intel.com
2016-02-19drm/i915: drop write perm from module params which don't support changingJani Nikula1-4/+4
We've given write permissions to dynamically change some module parameters through /sys/module/i915/parameters although they only support setting on module load. Fix the permissions. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455621493-6865-1-git-send-email-jani.nikula@intel.com
2016-02-19drm/i915/dsi: Using the bpp value wrt the pixel formatDeepak M4-8/+6
The bpp value which is used while calulating the txbyteclkhs values should be wrt the pixel format value. Currently bpp is coming from pipe config to calculate txbyteclkhs. Fix it in this patch. V2: dsi_pixel_format_bpp is used to retrieve the bpp from pixel_format [Review: Jani] Signed-off-by: Deepak M <m.deepak@intel.com> Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> # BYT Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455203007-10850-1-git-send-email-ramalingam.c@intel.com
2016-02-18drm/i915/bxt: Remove DSP CLK_GATE programming for BXTUma Shankar1-4/+7
DSP CLK_GATE registers are specific to BYT and CHT. Avoid programming the same for BXT platform. v2: Rebased on latest drm nightly branch. v3: Fixed Jani's review comments Signed-off-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455796166-13052-1-git-send-email-jani.nikula@intel.com
2016-02-18drm/i915/skl: Ensure HW is powered during DDB HW state readoutImre Deak1-1/+6
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com
2016-02-18drm/i915: Extract intel_encoder_has_connectors()Ville Syrjälä1-10/+12
We have an open coded loop which tries to see if the encoder has any connectors linked to it. Let's extract that to a helper similar to intel_crtc_has_encoders(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455737325-14777-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-18drm/i915: Use atomic state in intel_fb_initial_config.Maarten Lankhorst1-6/+11
This is another step in removing legacy state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-6-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/i915: Use correct dpms for intel_enable_crt.Maarten Lankhorst1-3/+1
With the conversion to atomic only on/off are still supported. The rest is mapped to one of those, and when enable is called DPMS_ON should be true. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-5-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/i915: Use atomic state in tv load detection.Maarten Lankhorst1-7/+4
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-4-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/i915: Use atomic state for load detect in crt.Maarten Lankhorst1-3/+3
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-3-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/i915: Use atomic state to obtain load detection crtc, v3.Maarten Lankhorst2-82/+54
Instead of restoring dpms and a flag for whether a temp fb is allocated duplicate an atomic state before the new state is committed, and commit it the old state in intel_release_load_detect_pipe. Changes since v1: - Use a real atomic state. (Ville) Changes since v2: - Do not preserve shared_dpll any more, no need to do so. (Ville) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-2-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/i915: Enable PSR by default on Haswell and Broadwell.Rodrigo Vivi1-1/+2
With a reliable frontbuffer tracking and all instability corner cases on Haswell and Broadwell solved let's re-enabled PSR by default on these platforms. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away. If this is the case PSR is the culprit so after that please check if i915.enable_psr=2 or i915.enable_psr=3 solves your issue and please let us know. There are many panels out there and not all implementations apparently work as we would expect. In case you needed to force it on standby or disabled or in case of any PSR related bug please report it at bugs.freedesktop.org. In a bugzilla entry for PSR is desirable: - dmesg (drm.debug=0xe) - output of /sys/kernel/debug/dri/0/i915_edp_psr_status - Platform information. Vendor, model, id, pci id. - Graphical environment: Gnome, KDE, openbox, etc... - Details how to reproduce. - Also good if you could run PSR test cases of Intel-gpu-tools - Please mention if forcing main link standby or main link off helps you. There are Intel-gpu-tools test cases that can be helpful to determine if PSR is working as expected: kms_psr_sink_crc and kms_psr_frontbuffer_tracking. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455278893-1307-2-git-send-email-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-18drm/i915: Enable PSR by default on Valleyview and Cherryview.Rodrigo Vivi1-1/+4
With a reliable frontbuffer tracking and all instability corner cases solved for this platform let's re-enabled PSR by default. In case a new issue is found and PSR is the main suspect, please check if i915.enable_psr=0 really makes your problem go away, please report it at bugs.freedesktop.org. In a bugzilla entry for PSR is desirable: - dmesg (drm.debug=0xe) - output of /sys/kernel/debug/dri/0/i915_edp_psr_status - Platform information. Vendor, model, id, pci id. - Graphical environment: Gnome, KDE, openbox, etc... - Details how to reproduce. - Also good if you could run PSR test cases of Intel-gpu-tools - Please mention if forcing main link standby or main link off helps you. There are Intel-gpu-tools test cases that can be helpful to determine if PSR is working as expected: kms_psr_sink_crc and kms_psr_frontbuffer_tracking. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-18drm/i915: Change i915.enable_psr parameter to use per platform default.Rodrigo Vivi2-2/+8
This will give us flexibility to enable PSR by default independently so issues and corner cases in one platform won't affect others were we have it working properly. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-17i915: cast before shifting in i915_pte_countAlan1-1/+1
Otherwise a pde_shift big enough to overflow a u32 will be truncated before assignment Note: We never asked for ranges spanning a 4G boundary, so this issue doesn't cause a real problem. Signed-off-by: Alan Cox <alan@linux.intel.com> [danvet: Add note why this isn't a real problem.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160217142043.4947.60447.stgit@localhost.localdomain
2016-02-17drm/i915/lvds: Ensure the HW is powered during HW state readoutImre Deak1-3/+11
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/hdmi: Ensure the HW is powered during HW state readoutImre Deak1-3/+11
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/dsi: Ensure the HW is powered during HW state readoutImre Deak1-3/+10
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/dp: Ensure the HW is powered during HW state readoutImre Deak1-4/+14
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Ensure the HW is powered when accessing the CRC HW blockImre Deak1-7/+21
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. While at it also add the missing reference around the HW access in i915_interrupt_info(). v2: - update the commit message mentioning that this also fixes the HW access in the interrupt info debugfs entry (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/ddi: Ensure the HW is powered during HW state readoutImre Deak1-33/+79
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/crt: Ensure the HW is powered during HW state readoutImre Deak1-3/+10
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Ensure the HW is powered during HW access in assert_pipeImre Deak1-4/+7
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Ensure the HW is powered when disabling VGAImre Deak1-1/+3
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com
2016-02-17drm/i915/ibx: Ensure the HW is powered during PLL HW readoutImre Deak1-1/+3
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Ensure the HW is powered during display pipe HW readoutImre Deak1-19/+48
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Revieved-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Add helper to get a display power ref if it was already enabledImre Deak2-9/+94
We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
2016-02-17drm/i915: Add an optional selection from i915 of CONFIG_MMU_NOTIFIERChris Wilson1-0/+11
userptr requires mmu-notifier for full unprivileged support. Most systems have mmu-notifier support already enabled as a requirement for virtualisation support, but we should make the option for i915 to take advantage of mmu-notifiers explicit (and enable by default so that regular userspace can take advantage of passing client memory to the GPU.) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1452503961-14837-3-git-send-email-chris@chris-wilson.co.uk
2016-02-16drm/i915: Lock mode_config.mutex in intel_display_resume.Maarten Lankhorst1-0/+8
Unfortunately i915 is still not fully atomic, and expects mode_config.mutex to be held during modeset until we finally fix it. This fixes the following WARN when resuming: [ 425.208983] ------------[ cut here ]------------ [ 425.208990] WARNING: CPU: 0 PID: 6828 at drivers/gpu/drm/drm_edid.c:3555 drm_select_eld+0xa5/0xd0() [ 425.209015] Modules linked in: pl2303 usbserial snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_hda_core snd_pcm i2c_hid i2c_designware_platform i2c_designware_core r8169 mii sdhci_acpi sdhci mmc_core [ 425.209018] CPU: 0 PID: 6828 Comm: kworker/u4:5 Tainted: G U W 4.5.0-rc4-gfxbench+ #1 [ 425.209020] Hardware name: \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff \xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff\xffffffff/DN2820FYK, BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014 [ 425.209027] Workqueue: events_unbound async_run_entry_fn [ 425.209032] 0000000000000000 ffff880072433958 ffffffff813f6b05 0000000000000000 [ 425.209036] ffffffff81aaef2d ffff880072433990 ffffffff81078291 ffff880036b933d8 [ 425.209039] ffff88006d528000 ffff88006d52b3d8 ffff88006d52b3d8 ffff88007315b6f8 [ 425.209040] Call Trace: [ 425.209045] [<ffffffff813f6b05>] dump_stack+0x67/0x92 [ 425.209049] [<ffffffff81078291>] warn_slowpath_common+0x81/0xc0 [ 425.209052] [<ffffffff81078385>] warn_slowpath_null+0x15/0x20 [ 425.209054] [<ffffffff8151e195>] drm_select_eld+0xa5/0xd0 [ 425.209101] [<ffffffffa01f34f4>] intel_audio_codec_enable+0x44/0x160 [i915] [ 425.209135] [<ffffffffa023eac7>] intel_enable_hdmi_audio+0x87/0x90 [i915] [ 425.209169] [<ffffffffa023eb5a>] g4x_enable_hdmi+0x8a/0xa0 [i915] [ 425.209202] [<ffffffffa023f41b>] vlv_hdmi_pre_enable+0x1cb/0x240 [i915] [ 425.209236] [<ffffffffa020edcf>] valleyview_crtc_enable+0x10f/0x290 [i915] [ 425.209270] [<ffffffffa020ba49>] intel_atomic_commit+0x769/0x17a0 [i915] [ 425.209274] [<ffffffff81526ad5>] ? drm_atomic_check_only+0x145/0x660 [ 425.209276] [<ffffffff81527022>] drm_atomic_commit+0x32/0x50 [ 425.209310] [<ffffffffa0215fa0>] intel_display_resume+0xa0/0x130 [i915] [ 425.209338] [<ffffffffa018c1bb>] i915_drm_resume+0xcb/0x160 [i915] [ 425.209366] [<ffffffffa018c272>] i915_pm_resume+0x22/0x30 [i915] [ 425.209370] [<ffffffff8143d91e>] pci_pm_resume+0x6e/0xe0 [ 425.209373] [<ffffffff8143d8b0>] ? pci_pm_resume_noirq+0xa0/0xa0 [ 425.209375] [<ffffffff815409ae>] dpm_run_callback+0x6e/0x280 [ 425.209378] [<ffffffff815410b2>] device_resume+0x92/0x250 [ 425.209380] [<ffffffff81541288>] async_resume+0x18/0x40 [ 425.209382] [<ffffffff8109c7a5>] async_run_entry_fn+0x45/0x140 [ 425.209386] [<ffffffff81093293>] process_one_work+0x1e3/0x620 [ 425.209388] [<ffffffff810931f7>] ? process_one_work+0x147/0x620 [ 425.209391] [<ffffffff81093719>] worker_thread+0x49/0x490 [ 425.209393] [<ffffffff810936d0>] ? process_one_work+0x620/0x620 [ 425.209396] [<ffffffff81099e0a>] kthread+0xea/0x100 [ 425.209400] [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0 [ 425.209404] [<ffffffff817ba03f>] ret_from_fork+0x3f/0x70 [ 425.209407] [<ffffffff81099d20>] ? kthread_create_on_node+0x1f0/0x1f0 [ 425.209409] ---[ end trace d1b247107f34a8b2 ]--- Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455632862-18557-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-16drm/i915: Fix some minor issues with atomic cdclk.Maarten Lankhorst1-8/+4
The check for active_crtcs == 0 was performed by the callers, when changing the patches I forgot to remove those hunks. This resulted in skylake scalers still not having the correct cdclk to calculate scaling when all crtc's were dpms off. Fixes: 1a617b77658e ("drm/i915: Keep track of the cdclk as if all crtc's were active.") Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455614711-9045-1-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-02-16drm/i915: Use atomic helpers for suspend, v2.Maarten Lankhorst3-85/+45
Instead of duplicating the functionality now that we no longer need to preserve dpll state we can move to using the upstream suspend helper. Changes since v1: - Call hw readout with all mutexes held. - Rework intel_display_suspend to only assign modeset_restore_state on success. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56C2E686.5060803@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-02-15drm/i915: Check for get_pages instead of shmem (filp)Ben Widawsky1-1/+1
This behavior of checking for a shmem backed GEM object was introduced here: commit 4c914c0c7c787b8f730128a8cdcca9c50b0784ab Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Tue Feb 18 10:15:45 2014 -0800 drm/i915: Refactor shmem pread setup It is possible for an object to not be a shmem backed GEM object (for example userptr objects). An example of how we hit this failure can be found through copy_batch() in the command parser because we allocate a userptr object for the batch which contains privileged instructions. Userptr calls drm_gem_private_object_init() which explicitly sets the filp to none. NOTE: I manually retyped this from a test machine. So I haven't even compiled this exact patch. v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kristian Høgsberg <krh@bitplanet.net> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> (v1) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455047053-2644-1-git-send-email-benjamin.widawsky@intel.com
2016-02-15drm/i915: Reject invalid-pad for context-destroy and -create ioctlsChris Wilson1-0/+6
Unknown parameters, especially structure padding, are expected to invoke rejection with -EINVAL. v2: similar issue exists for context-create Testcase: igt/gem_ctx_create/invalid-pad Testcase: igt/gem_ctx_bad_destroy/invalid-pad Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89602 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93999 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454690759-31201-1-git-send-email-chris@chris-wilson.co.uk
2016-02-15drm/i915: Add missing 'else' to intel_digital_port_connected()Ville Syrjälä1-1/+1
intel_digital_port_connected() lacks one 'else'. There's no actual harm in not having it since each branch has an unconditional return, so it can't accidentally end up in taking two branches instead of just the one. But let's be consistent and add the 'else' anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455201868-31527-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2016-02-15drm/i915: Fix hpd live status bits for g4xVille Syrjälä2-14/+15
Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nick Bowler <nbowler@draconx.ca> References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html Reported-by: Nick Bowler <nbowler@draconx.ca> Cc: stable@vger.kernel.org Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-15drm/i915/ilk: Move register read under spinlockTvrtko Ursulin1-2/+4
Code does read-modify-write but the read was outside the lock. It is fine since the caller holds struct mutex, but if we correct this we open up the opportunity for decreasing the mutex duration time since the call to ironlake_enable_drps does not need it any longer since it is covered by the mchdev_lock lock. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1455186452-13691-2-git-send-email-tvrtko.ursulin@linux.intel.com
2016-02-15drm/i915/guc: Do not wait for firmware load atomicallyTvrtko Ursulin1-3/+3
It does not look like this code needs to wait atomically? Higher in the call chain it calls the GEM API and I do not see that the section is under any spin locks or such. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Alex Dai <yu.dai@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com>
2016-02-15drm/i915: Fix struct mutex vs. RPS lock inversionTvrtko Ursulin2-9/+4
RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and instead only take it during the sections which need it. Also, struct_mutex is not needed any more since dedicated RPS lock was added in: commit 4fc688ce79772496503d22263d61b071a8fb596e Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 2 11:14:01 2012 -0700 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex Based on prototype patch by Chris Wilson and a subsequent mailing list discussion involving Ville, Imre, Chris and Daniel. v2: More details in the commit. v3: Use drm_gem_object_unreference_unlocked. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-02-15drm/i915: GEM operations need to be done under the big lockTvrtko Ursulin2-2/+8
VMA creation and GEM list management need the big lock. v2: Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) Not to mention drm_gem_object_unreference was there in existing code with no mutex held. v3: Some callers of i915_gem_object_create_stolen_for_preallocated already hold the lock so move the mutex into the other caller as well. v4: Changed to lockdep_assert_held. (Chris Wilson) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-02-15drm/i915: Use appropriate spinlock flavourTvrtko Ursulin1-4/+2
We know this never runs from interrupt context so don't need to use the flags variant. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-15drm/i915: Clear shared dpll based on old state, v2.Maarten Lankhorst1-13/+8
Atomic resume was preserving the dpll state because it was required for clearing pll state correctly. If we look at the old_crtc_state for pll to clear this is not needed and the hack can be removed. Changes since v1: - Rename dpll variable to old_dpll. (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455022343-15222-1-git-send-email-maarten.lankhorst@linux.intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-02-15Revert "drm/i915: fix context/engine cleanup order"Daniel Vetter3-15/+14
This reverts commit 1b39a917a9e00378c02c50ad86632ed3d872bfad. Chris retracted his reviewed-by (which I failed to notice) and somehow it blows up (I did it again!) as reported by Mika with the below backtrace on module reload: [ 58.170374] IP: [<ffffffffa00e04d3>] intel_logical_ring_cleanup+0x83/0x100 [i915] ... [ 58.170469] Call Trace: [ 58.170479] [<ffffffffa00d0ed4>] i915_gem_cleanup_engines+0x34/0x60 [i915] [ 58.170493] [<ffffffffa0154520>] i915_driver_unload+0x140/0x220 [i915] [ 58.170497] [<ffffffff8154a4f4>] drm_dev_unregister+0x24/0xa0 [ 58.170501] [<ffffffff8154aace>] drm_put_dev+0x1e/0x60 [ 58.170506] [<ffffffffa00912a0>] i915_pci_remove+0x10/0x20 [i915] [ 58.170510] [<ffffffff814766e4>] pci_device_remove+0x34/0xb0 [ 58.170514] [<ffffffff8156e7d5>] __device_release_driver+0x95/0x140 [ 58.170518] [<ffffffff8156e97c>] driver_detach+0xbc/0xc0 [ 58.170521] [<ffffffff8156d883>] bus_remove_driver+0x53/0xd0 [ 58.170525] [<ffffffff8156f3a7>] driver_unregister+0x27/0x50 [ 58.170528] [<ffffffff81475725>] pci_unregister_driver+0x25/0x70 [ 58.170531] [<ffffffff8154c274>] drm_pci_exit+0x74/0x90 [ 58.170543] [<ffffffffa0154cb0>] i915_exit+0x20/0x1aa [i915] [ 58.170548] [<ffffffff8111846f>] SyS_delete_module+0x18f/0x1f0 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-02-15drm/i915: Don't ERROR for an expected intel_rcs_ctx_init() interruptionChris Wilson1-2/+2
intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait upon a full ring to advance). Don't emit an error for this. Testcase: igt/gem_concurrent_blit Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454086145-16160-3-git-send-email-chris@chris-wilson.co.uk
2016-02-15drm/i915: Update DRIVER_DATE to 20160214Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-12drm/i915: edp resume/On time optimization.Abhay Kumar2-6/+15
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay calculation(Ville). v3: Addressed below comments 1. Tracking time from where last powercycle is initiated. 2. Used ktime_get_bootime() wrapper for boottime clock. 3. Used ktime_ms_delta() to get time difference. v4: Updated v3 change log in detail. v5: Removed static from panel_power_on_time(Stéphane). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Abhay Kumar <abhay.kumar@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1453513144-14135-1-git-send-email-abhay.kumar@intel.com
2016-02-12Merge tag 'topic/drm-misc-2016-02-12' into drm-intel-next-queuedDaniel Vetter9689-203580/+433538
Backmerge to get at the new encoder_mask support in atomic helpers. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2016-02-11drm/msm: remove unused variableArnd Bergmann1-1/+0
After the drm_device_is_unplugged() was removed, the 'dev' variable is now unused, and we get a warning for that: drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap': drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable] This removes the variable as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: e9f8250f2f92 ("drm/msm: remove the drm_device_is_unplugged check") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455181810-3910161-1-git-send-email-arnd@arndb.de
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-16 04:33:27 +0300