- 25 Feb, 2016 4 commits
-
-
Maarten Lankhorst authored
Commit 791a32be ("drm/i915: Drop intel_update_sprite_watermarks") removes the use of this variable, but forgot to remove it. Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-5-git-send-email-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Currently we perform our own wait in post_plane_update, but the atomic core performs another one in wait_for_vblanks. This means that 2 vblanks are done when a fb is changed, which is a bit overkill. Merge them by creating a helper function that takes a crtc mask for the planes to wait on. The broadwell vblank workaround may look gone entirely but this is not the case. pipe_config->wm_changed is set to true when any plane is turned on, which forces a vblank wait. Changes since v1: - Removing the double vblank wait on broadwell moved to its own commit. Changes since v2: - Move out POWER_DOMAIN_MODESET handling to its own commit. Changes since v3: - Do not wait for vblank on legacy cursor updates. (Ville) - Move broadwell vblank workaround comment to page_flip_finished. (Ville) Changes since v4: - Compile fix, legacy_cursor_flip -> *_update. Changes since v5: - Kill brackets. - Add WARN_ON when wait_for_vblanks fails. - Remove extra newlines. - Split the checks whether vblank is needed to a separate function, with comments why a vblank is needed. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Maarten Lankhorst authored
Right now there's separate power domain handling for update_pipe and modesets. Unify this and only grab POWER_DOMAIN_MODESET once. Signed-off-by:
-
Maarten Lankhorst authored
Use our newly created encoder_mask to iterate over the encoders. This makes it possible to get the crtc power domains from the crtc_state at any time, without any locks or having to look at the legacy state. Signed-off-by:
-
- 22 Feb, 2016 8 commits
-
-
Ville Syrjälä authored
for_each_pipe_masked() can be used to iterate over the pipes included in the user provided pipe mask. Removes a few lines of duplicated code. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by:
-
Ville Syrjälä authored
After we've told the irq code we don't want to handle display irqs anymore, we must make sure any display irq handling already kicked off has finished before we actually turn off the power well. I wouldn't expect PIPESTAT based interrupts to occur anymore since vblanks/page flips/gmbus/etc should all be quiescent at this point. But at least hotplug interrupts could still occur. Hotplug interrupts may also kick off the workqueue based hotplug processing, but that code should take the required power domain references itself, so there shouldn't be any need to synchronize with the hotplug processing from the power well code. Signed-off-by:
-
Ville Syrjälä authored
PIPESTAT registers live in the display power well on VLV/CHV, so we shouldn't access them when things are powered down. Let's check whether the display interrupts are on or off before accessing the PIPESTAT registers. Another option would be to read the PIPESTAT registers only when the IIR register indicates that there's a pending pipe event. But that would mean we might miss even more underrun reports than we do now, because the underrun status bit lives in PIPESTAT but doesn't actually generate an interrupt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93738 Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Mika Kuoppala authored
DMC debugmask bits should stick so no need to write them everytime dc state is changed. v2: Write after firmware has been successfully loaded (Ville) Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
-
Mika Kuoppala authored
Cores need to be included into the debug mask. We don't exactly know what it does but the spec says it must be enabled. So obey. v2: Cores should be only set for BXT (Imre, Art) Cc: Imre Deak <imre.deak@intel.com> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Signed-off-by:
-
Mika Kuoppala authored
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:
-
Patrik Jakobsson authored
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:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
- 19 Feb, 2016 4 commits
-
-
Paulo Zanoni authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455655643-2535-1-git-send-email-paulo.r.zanoni@intel.com
-
Jani Nikula authored
This is a manual revert of commit 7a10dfa6 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:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455621493-6865-2-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
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:
-
Deepak M authored
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:
-
- 18 Feb, 2016 8 commits
-
-
Uma Shankar authored
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:
-
Imre Deak authored
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:
-
Ville Syrjälä authored
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:
-
Maarten Lankhorst authored
This is another step in removing legacy state. Signed-off-by:
-
Maarten Lankhorst authored
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 authored
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:
-
- 17 Feb, 2016 16 commits
-
-
Rodrigo Vivi authored
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.comSigned-off-by:
-
Rodrigo Vivi authored
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 authored
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:
-
Alan authored
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:
-
Imre Deak authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com
-
