Elsewhere we have adopted the convention of using '_link' to denote
elements in the list (and '_list' for the actual list_head itself), and
that the name should indicate which list the link belongs to (and
preferrably not just where the link is being stored).
s/vma_link/obj_link/ (we iterate over obj->vma_list)
s/mm_list/vm_link/ (we iterate over vm->[in]active_list)
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Tvrtko Ursulin <[email protected]>
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: Maarten Lankhorst <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Paulo Zanoni <[email protected]>
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ä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>
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ä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>
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 <[email protected]>
Tested-by: Chris Wilson <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Imre Deak <[email protected]>
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 <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Signed-off-by: Yogesh Mohan Marimuthu <[email protected]>
Signed-off-by: Ramalingam C <[email protected]>
Tested-by: Mika Kahola <[email protected]> # BYT
Signed-off-by: Jani Nikula <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]>
[danvet: Add note why this isn't a real problem.]
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Revieved-by: Mika Kuoppala <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
CC: Chris Wilson <[email protected]>
CC: Joonas Lahtinen <[email protected]>
CC: Ville Syrjälä <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]>
Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Ville Syrjälä <[email protected]>
