aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2016-02-22drm/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 <[email protected]> Revieved-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 1729050eb4bbc192e54069e82069f2811313c1dd) Signed-off-by: Jani Nikula <[email protected]>
2016-02-22drm/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 <[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] (cherry picked from commit 09731280028ce03e6a27e1998137f1775a2839f3) Signed-off-by: Jani Nikula <[email protected]>
2016-02-22drm/i915/gen9: Write dc state debugmask bits only onceMika Kuoppala3-9/+8
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 <[email protected]> Reviewed-by: Imre Deak <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-02-22drm/i915/gen9: Extend dmc debug mask to include coresMika Kuoppala2-6/+11
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 <[email protected]> Cc: Runyan, Arthur J <[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]
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 <[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]
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 <[email protected]> Signed-off-by: Patrik Jakobsson <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2016-02-20drm: rcar-du: Move plane allocator to rcar_du_plane.cLaurent Pinchart3-275/+290
The plane allocator is specific to DU planes and won't be used for VSP-based planes, move it with the rest of the DU planes code where it belongs. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Restart the DU group when a plane source changesLaurent Pinchart4-2/+28
Plane sources are configured by the VSPS bit in the PnDDCR4 register. Although the datasheet states that the bit is updated during vertical blanking, it seems that updates only occur when the DU group is held in reset through the DSYSR.DRES bit. Restart the group if the source changes. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Add VSP1 compositor supportLaurent Pinchart6-49/+82
Configure the plane source at plane setup time to source frames from memory or from the VSP1. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Add VSP1 support to the planes allocatorLaurent Pinchart3-6/+44
The R8A7790 DU can source frames directly from the VSP1 devices VSPD0 and VSPD1. VSPD0 feeds DU0/1 plane 0, and VSPD1 feeds either DU2 plane 0 or DU0/1 plane 1. Allocate the correct fixed plane when sourcing frames from VSPD0 or VSPD1, and allocate planes in reverse index order otherwise to ensure maximum availability of planes 0 and 1. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Refactor plane setupLaurent Pinchart1-18/+21
Rename plane setup functions using more explicit names, and use local variables to store intermediate values to increase readability. This also prepares for VSP compositor support. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Compute plane DDCR4 register value directlyLaurent Pinchart1-10/+3
There's no need for a read-modify-write pattern, all register bits can be set explicitly. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Don't update planes on disabled CRTCsLaurent Pinchart1-1/+1
A disabled CRTC can't display planes, the driver shouldn't try to configure it when updating planes. The DRM core will store the plane state for us, and the plane will be configured appropriately the next time the CRTC is enabled. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Remove local CRTC enabled stateLaurent Pinchart2-13/+1
The atomic framework guarantees that the CRTC enable and disable functions will only be called when needed, there's no need to duplicate the CRTC state check. By replacing the local CRTC enabled state check at resume time with the CRTC active state we can remove the local CRTC enabled state altogether. Signed-off-by: Laurent Pinchart <[email protected]>
2016-02-20drm: rcar-du: Perform initialization/cleanup at probe/remove timeLaurent Pinchart4-114/+106
The drm driver .load() operation is prone to race conditions as it initializes the driver after registering the device nodes. Its usage is deprecated, inline it in the probe function and call drm_dev_alloc() and drm_dev_register() explicitly. For consistency inline the .unload() handler in the remove function as well. Signed-off-by: Laurent Pinchart <[email protected]> Acked-by: Daniel Vetter <[email protected]>
2016-02-19drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.Mario Kleiner1-3/+15
This fixes a regression introduced in Linux 4.4. This is a port of the same fix for radeon-kms in the patch "drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)" Limit the amount of time amdgpu_flip_work_func can delay programming a page flip, by both limiting the maximum amount of time per wait cycle and the maximum number of wait cycles. Continue the flip if the limit is exceeded, even if that may result in a visual or timing glitch. This is to prevent a hang of page flips, as reported in fdo bug #93746: Disconnecting a DisplayPort display in parallel to a kms pageflip getting queued can cause the following hang of page flips and thereby an unusable desktop: 1. kms pageflip ioctl() queues pageflip -> queues execution of amdgpu_flip_work_func. 2. Hotunplug of display causes the driver to DPMS OFF the unplugged display. Display engine shuts down, scanout no longer moves, but stays at its resting position at start line of vblank. 3. amdgpu_flip_work_func executes while crtc is off, and due to the non-moving scanout position, the new flip delay code introduced into Linux 4.4 by commit 8e36f9d33c13 ("drm/amdgpu: Fixup hw vblank counter/ts..") enters an infinite wait loop. 4. After reconnecting the display, the pageflip continues to hang in 3. and the display doesn't update its view of the desktop. This patch fixes the Linux 4.4 regression from fdo bug #93746 <https://bugs.freedesktop.org/show_bug.cgi?id=93746> Reported-by: Bernd Steinhauser <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Cc: <[email protected]> # 4.4+ Cc: Michel Dänzer <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-02-19drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)Mario Kleiner1-2/+15
This fixes a regression introduced in Linux 4.4. Limit the amount of time radeon_flip_work_func can delay programming a page flip, by both limiting the maximum amount of time per wait cycle and the maximum number of wait cycles. Continue the flip if the limit is exceeded, even if that may result in a visual or timing glitch. This is to prevent a hang of page flips, as reported in fdo bug #93746: Disconnecting a DisplayPort display in parallel to a kms pageflip getting queued can cause the following hang of page flips and thereby an unusable desktop: 1. kms pageflip ioctl() queues pageflip -> queues execution of radeon_flip_work_func. 2. Hotunplug of display causes the driver to DPMS OFF the unplugged display. Display engine shuts down, scanout no longer moves, but stays at its resting position at start line of vblank. 3. radeon_flip_work_func executes while crtc is off, and due to the non-moving scanout position, the new flip delay code introduced into Linux 4.4 by commit 5b5561b3660d ("drm/radeon: Fixup hw vblank counter/ts..") enters an infinite wait loop. 4. After reconnecting the display, the pageflip continues to hang in 3. and the display doesn't update its view of the desktop. This patch fixes the Linux 4.4 regression from fdo bug #93746 <https://bugs.freedesktop.org/show_bug.cgi?id=93746> v2: Skip wait immediately if !radeon_crtc->enabled, as suggested by Michel. Reported-by: Bernd Steinhauser <[email protected]> Signed-off-by: Mario Kleiner <[email protected]> Tested-by: Bernd Steinhauser <[email protected]> Cc: <[email protected]> # 4.4+ Cc: Michel Dänzer <[email protected]> Cc: Alex Deucher <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> 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 <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[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]
2016-02-19drm/nouveau: use post-decrement in error handlingRasmus Villemoes1-1/+1
We need to use post-decrement to get the dma_map_page undone also for i==0, and to avoid some very unpleasant behaviour if dma_map_page failed already at i==0. Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Ben Skeggs <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2016-02-19drm/atomic: Allow for holes in connector state, v2.Maarten Lankhorst3-54/+41
Because we record connector_mask using 1 << drm_connector_index now the connector_mask should stay the same even when other connectors are removed. This was not the case with MST, in that case when removing a connector all other connectors may change their index. This is fixed by waiting until the first get_connector_state to allocate connector_state, and force reallocation when state is too small. As a side effect connector arrays no longer have to be preallocated, and can be allocated on first use which means a less allocations in the page flip only path. Changes since v1: - Whitespace. (Ville) - Call ida_remove when destroying the connector. (Ville) - u32 alloc -> int. (Ville) Fixes: 14de6c44d149 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.") Signed-off-by: Maarten Lankhorst <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Lyude <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2016-02-19Merge branch 'drm-rockchip-next-2016-02-18' of ↵Dave Airlie4-0/+1309
https://github.com/markyzq/kernel-drm-rockchip into drm-next add Innosilicon HDMI support. * 'drm-rockchip-next-2016-02-18' of https://github.com/markyzq/kernel-drm-rockchip: dt-bindings: add document for Innosilicon HDMI on Rockchip platform drm/rockchip: hdmi: add Innosilicon HDMI support
2016-02-19Merge tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux into drm-nextDave Airlie6-122/+872
This pull request brings in overlay plane support for vc4. * tag 'drm-vc4-next-2016-02-17' of github.com:anholt/linux: drm/vc4: Add support for YUV planes. drm/vc4: Add support a few more RGB display plane formats. drm/vc4: Add support for scaling of display planes. drm/vc4: Fix which value is being used for source image size. drm/vc4: Add more display planes to each CRTC. drm/vc4: Make the CRTCs cooperate on allocating display lists. drm/vc4: Add a proper short-circut path for legacy cursor updates. drm/vc4: Move the plane clipping/scaling setup to a separate function. drm/vc4: Add missing __iomem annotation to hw_dlist. drm/vc4: Improve comments on vc4_plane_state members.
2016-02-19Merge tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux into drm-fixesDave Airlie7-52/+118
This pull request fixes GPU reset (which was disabled shortly after V3D integration due to build breakage) and waits for idle in the presence of signals (which X likes to do a lot). * tag 'drm-vc4-fixes-2016-02-17' of github.com:anholt/linux: drm/vc4: Use runtime PM to power cycle the device when the GPU hangs. drm/vc4: Enable runtime PM. drm/vc4: Fix spurious GPU resets due to BO reuse. drm/vc4: Drop error message on seqno wait timeouts. drm/vc4: Fix -ERESTARTSYS error return from BO waits. drm/vc4: Return an ERR_PTR from BO creation instead of NULL. drm/vc4: Fix the clear color for the first tile rendered. drm/vc4: Validate that WAIT_BO padding is cleared.
2016-02-19Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2-2/+2
into drm-fixes Just two small fixes in the ttm_tt_populate error handling; one for radeon, one for amdgpu. * 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: use post-decrement in error handling drm/amdgpu: use post-decrement in error handling
2016-02-19Merge tag 'drm-intel-fixes-2016-02-18' of ↵Dave Airlie2-14/+15
git://anongit.freedesktop.org/drm-intel into drm-fixes single g4x hpd fix. * tag 'drm-intel-fixes-2016-02-18' of git://anongit.freedesktop.org/drm-intel: drm/i915: Fix hpd live status bits for g4x
2016-02-19Merge branch 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie86-4365/+5486
into drm-next First radeon and amdgpu pull request for 4.6. Highlights: - ACP support for APUs with i2s audio - CS ioctl optimizations - GPU scheduler optimizations - GPUVM optimizations - Initial GPU reset support (not enabled yet) - New powerplay sysfs interface for manually selecting clocks - Powerplay fixes - Virtualization fixes - Removal of hw semaphore support - Lots of other misc fixes and cleanups * 'drm-next-4.6' of git://people.freedesktop.org/~agd5f/linux: (118 commits) drm/amdgpu: Don't call interval_tree_remove in amdgpu_mn_destroy drm/amdgpu: Fix race condition in amdgpu_mn_unregister drm/amdgpu: cleanup gem init/finit drm/amdgpu: rework GEM info printing drm/amdgpu: print the GPU offset as well in gem_info drm/amdgpu: optionally print the pin count in gem_info as well drm/amdgpu: print the BO size only once in amdgpu_gem_info drm/amdgpu: print pid as integer drm/amdgpu: remove page flip work queue v3 drm/amdgpu: stop blocking for page filp fences drm/amdgpu: stop calling amdgpu_gpu_reset from the flip code drm/amdgpu: remove fence reset detection leftovers drm/amdgpu: Fix race condition in MMU notifier release drm/radeon: Fix WARN_ON if DRM_DP_AUX_CHARDEV is enabled drm/amdgpu/vi: move uvd tiling config setup into uvd code drm/amdgpu/vi: move sdma tiling config setup into sdma code drm/amdgpu/cik: move uvd tiling config setup into uvd code drm/amdgpu/cik: move sdma tiling config setup into sdma code drm/amdgpu/gfx7: rework gpu_init() drm/amdgpu/gfx: clean up harvest configuration (v2) ...
2016-02-19Merge tag 'topic/drm-misc-2016-02-18' of ↵Dave Airlie67-365/+753
git://anongit.freedesktop.org/drm-intel into drm-next Misc stuff all over: - more mode_fixup removal from Carlos, there's another final pile still left. - final bits of vgaswitcheroo from Lukas for apple gmux, we're still discussing an api cleanup patch to make it a bit more abuse-safe as a follow-up - dp aux interface for userspace for tools&tests from Rafael Antognolli - actual interface parts for dma-buf flushing for userspace mmap - few small bits all over - vgaswitcheroo support for apple gmux from Lukas Wunner - checks for ->mode_fixup in non-atomic helpers from Carlos Palminha, plus removing dummy funcs from drivers. Carlos promised to follow up with more, since there's lots more silly dummy functions around. - dma-buf patches from Tiago, except the ioctl itself (that needed a respin to address review from David Herrmann) - encoder mask for atomic from Maarten - bunch of random things all over. * tag 'topic/drm-misc-2016-02-18' of git://anongit.freedesktop.org/drm-intel: (57 commits) drm/udl: Use module_usb_driver drm: fixes crct set_mode when crtc mode_fixup is null. drm/tilcdc: removed optional dummy encoder mode_fixup function. drm/sti: removed optional dummy encoder mode_fixup function. drm/rockchip: removed optional dummy encoder mode_fixup function. drm/qxl: removed optional dummy encoder mode_fixup function. drm/mgag200: removed optional dummy encoder mode_fixup function. drm/msm/mdp: removed optional dummy encoder mode_fixup function. drm/imx: removed optional dummy encoder mode_fixup function. drm/gma500: removed optional dummy encoder mode_fixup function. drm/radeon: removed optional dummy encoder mode_fixup function. drm/cirrus: removed optional dummy encoder mode_fixup function. drm/bochs: removed optional dummy encoder mode_fixup function. drm/ast: removed optional dummy encoder mode_fixup function. drm/amdgpu: removed optional dummy encoder mode_fixup function. drm/exynos: removed optional dummy encoder mode_fixup function. drm/udl: removed optional dummy encoder mode_fixup function. drm/virtio: removed optional dummy encoder mode_fixup function. drm/fb_helper: Use add_one_connector in add_all_connectors. drm/fb_helper: Use correct allocation count for arrays. ...
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 <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441 CC: Chris Wilson <[email protected]> Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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ä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]>
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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> 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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> 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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> 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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> 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 <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/1455697119-31416-2-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-18drm/rockchip: hdmi: add Innosilicon HDMI supportYakir Yang4-0/+1309
The Innosilicon HDMI is a low power HDMI 1.4 transmitter IP, and it have been integrated on some rockchip CPUs (like RK3036, RK312x). Signed-off-by: Yakir Yang <[email protected]> Tested-by: Heiko Stuebner <[email protected]>
2016-02-17drm/amdgpu: Don't call interval_tree_remove in amdgpu_mn_destroyFelix Kuehling1-1/+0
rbtree_postorder_for_each_entry_safe can skip over some entries if the tree is rebalanced in interval_tree_remove. interval_tree_remove is also redundant when the tree is just about to be freed. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]>
2016-02-17drm/amdgpu: Fix race condition in amdgpu_mn_unregisterFelix Kuehling1-10/+13
Exchange locking order of adev->mn_lock and mm_sem, so that rmn->mm->mmap_sem can be taken safely, protected by adev->mn_lock, when amdgpu_mn_destroy runs concurrently. Signed-off-by: Felix Kuehling <[email protected]> Reviewed-by: Christian König <[email protected]>
2016-02-17drm/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 <[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]>
2016-02-17drm/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 <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
2016-02-17drm/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 <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Reviewed-by: Daniel Vetter <[email protected]>
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 <[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]
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
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 <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.