aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-11-11drm/i915: Kill intel_runtime_pm_disable()Ville Syrjälä1-17/+0
intel_runtime_pm_disable() takes an extra rpm reference which combined with the one we leak from intel_display_set_init_power() leaves the usage count at <original>+1 after the driver has been unloaded. The original ref is dropped explicitly in intel_runtime_pm_enable(). So the next time we load the driver we can no longer do runtime PM ever. This used to work, but commit 292b990e86ab ("drm/i915: Update power domains on readout.") broke things by not dropping the init power domain during fbdev teardown. Based on the comment in intel_power_domains_fini(), the way it used to to work wasn't intentional. As in we weren't supposed to drop the init power during driver unload. And since we no longer do, we now leak an extra rpm reference. So fix things by throwing intel_runtime_pm_disable() to the bin, so that the only leaked reference comes from the init power domain. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Stone <daniels@collabora.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Fixes: 292b990e86ab ("drm/i915: Update power domains on readout.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10Merge branch 'akpm' (patches from Andrew)Linus Torvalds1-2/+5
Merge final patch-bomb from Andrew Morton: "Various leftovers, mainly Christoph's pci_dma_supported() removals" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: pci: remove pci_dma_supported usbnet: remove ifdefed out call to dma_supported kaweth: remove ifdefed out call to dma_supported sfc: don't call dma_supported nouveau: don't call pci_dma_supported netup_unidvb: use pci_set_dma_mask insted of pci_dma_supported cx23885: use pci_set_dma_mask insted of pci_dma_supported cx25821: use pci_set_dma_mask insted of pci_dma_supported cx88: use pci_set_dma_mask insted of pci_dma_supported saa7134: use pci_set_dma_mask insted of pci_dma_supported saa7164: use pci_set_dma_mask insted of pci_dma_supported tw68-core: use pci_set_dma_mask insted of pci_dma_supported pcnet32: use pci_set_dma_mask insted of pci_dma_supported lib/string.c: add ULL suffix to the constant definition hugetlb: trivial comment fix selftests/mlock2: add ULL suffix to 64-bit constants selftests/mlock2: add missing #define _GNU_SOURCE
2015-11-10Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds6-1/+19
Pull drm fixes from Dave Airlie: "Two build fixes, one for VC4, one for nouveau where the ARM only code is doing something a bit strange. While people are discussing that, just workaround it and fix the build for now. The code in question will never get used on anything non-ARM anyways. Also one fix for AST that SuSE had been hiding in their kernel, that allows all fbdev apps to work on that driver" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: fix build failures on all non ARM. drm/ast: Initialized data needed to map fbdev memory drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPER
2015-11-11drm/nouveau: fix build failures on all non ARM.Dave Airlie1-0/+6
gk20a is an ARM only GPU, so we can just do the correct thing on ARM but fail on other architectures. The other option was to use SWIOTLB as the define, which means phys_to_page exists, but this seems clearer. Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-11drm/ast: Initialized data needed to map fbdev memoryEgbert Eich4-0/+11
Due to a missing initialization there was no way to map fbdev memory. Thus for example using the Xserver with the fbdev driver failed. This fix adds initialization for fix.smem_start and fix.smem_len in the fb_info structure, which fixes this problem. Requested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: stable@vger.kernel.org Signed-off-by: Egbert Eich <eich@suse.de> [pulled from SuSE tree by me - airlied] Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-10nouveau: don't call pci_dma_supportedChristoph Hellwig1-2/+5
Just try to set a 64-bit DMA mask first and retry with the smaller dma_mask if dma_set_mask failed. Signed-off-by: Christoph Hellwig <hch@lst.de> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alexandre Courbot <acourbot@nvidia.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thierry Reding <treding@nvidia.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-11-10drm/i915: Setup DDI clk for MST on SKLVille Syrjälä3-27/+32
Set up the DDI->PLL mapping on SKL also for MST links. Might help make MST operational on SKL. v2: Rebased due to KBL Improve the patch subject, Jesse provided the new one Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1439826380-18403-1-git-send-email-ville.syrjala@linux.intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=91791 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds425-9472/+52394
Pull drm updates from Dave Airlie: "I Was Almost Tempted To Capitalise Every Word, but then I decided I couldn't read it myself! I've also got one pull request for the sti driver outstanding. It relied on a commit in Greg's tree and I didn't find out in time, that commit is in your tree now so I might send that along once this is merged. I also had the accidental misfortune to have access to a Skylake on my desk for a few days, and I've had to encourage Intel to try harder, which seems to be happening now. Here is the main drm-next pull request for 4.4. Highlights: New driver: vc4 driver for the Rasberry Pi VPU. (From Eric Anholt at Broadcom.) Core: Atomic fbdev support Atomic helpers for runtime pm dp/aux i2c STATUS_UPDATE handling struct_mutex usage cleanups. Generic of probing support. Documentation: Kerneldoc for VGA switcheroo code. Rename to gpu instead of drm to reflect scope. i915: Skylake GuC firmware fixes HPD A support VBT backlight fallbacks Fastboot by default for some systems FBC work BXT/SKL workarounds Skylake deeper sleep state fixes amdgpu: Enable GPU scheduler by default New atombios opcodes GPUVM debugging options Stoney support. Fencing cleanups. radeon: More efficient CS checking nouveau: gk20a instance memory handling improvements. Improved PGOB detection and GK107 support Kepler GDDR5 PLL statbility improvement G8x/GT2xx reclock improvements new userspace API compatiblity fixes. virtio-gpu: Add 3D support - qemu 2.5 has it merged for it's gtk backend. msm: Initial msm88896 (snapdragon 8200) exynos: HDMI cleanups Enable mixer driver byt default Add DECON-TV support vmwgfx: Move to using memremap + fixes. rcar-du: Add support for R8A7793/4 DU armada: Remove support for non-component mode Improved plane handling Power savings while in DPMS off. tda998x: Remove unused slave encoder support Use more HDMI helpers Fix EDID read handling dwhdmi: Interlace video mode support for ipu-v3/dw_hdmi Hotplug state fixes Audio driver integration imx: More color formats support. tegra: Minor fixes/improvements" [ Merge fixup: remove unused variable 'dev' that had all uses removed in commit 4e270f088011: "drm/gem: Drop struct_mutex requirement from drm_gem_mmap_obj" ] * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits) drm/vmwgfx: Relax irq locking somewhat drm/vmwgfx: Properly flush cursor updates and page-flips drm/i915/skl: disable display side power well support for now drm/i915: Extend DSL readout fix to BDW and SKL. drm/i915: Do graphics device reset under forcewake drm/i915: Skip fence installation for objects with rotated views (v4) vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT drm/amdgpu: group together common fence implementation drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE drm/amdgpu: remove now unused fence functions drm/amdgpu: fix fence fallback check drm/amdgpu: fix stoping the scheduler timeout drm/amdgpu: cleanup on error in amdgpu_cs_ioctl() drm/i915: Fix locking around GuC firmware load drm/amdgpu: update Fiji's Golden setting drm/amdgpu: update Fiji's rev id drm/amdgpu: extract common code in vi_common_early_init drm/amd/scheduler: don't oops on failure to load drm/amdgpu: don't oops on failure to load (v2) drm/amdgpu: don't VT switch on suspend ...
2015-11-10drm/i915: Configure eDP PLL freq from ironlake_edp_pll_on()Ville Syrjälä1-26/+19
ironlake_set_pll_cpu_edp() only gets called just before ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on(). Also toss in a debug print into ironlake_edp_pll_off() to match the one we have in ironlake_edp_pll_on(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-15-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Use intel_dp->DP in eDP PLL setupVille Syrjälä1-27/+14
Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs. To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later, so that we don't enable audio accidentally while configuring the PLL. Note that actually we already enabled audio before the port due to the double port register write magic required by VLV/CHV from 7b713f50d78b6 ("drm/i915: Fix eDP link training when switching pipes on VLV/CHV") So that gets changed now to keep audio off as long as the port is off. Also intel_dp_link_down() must be made to update intel_dp->DP so that we don't re-enable the port by accident when turning off the PLL. This is safe now that we don't call intel_dp_link_down() during link retraining. v2: Add a note about the audio vs. port enable (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447164977-32315-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2015-11-10drm/i915: Clean up eDP PLL state assertsVille Syrjälä1-15/+39
Rewrite the eDP PLL state asserts to conform to our usual state assert style. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-13-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Remove ILK-A eDP PLL workaround notesVille Syrjälä1-4/+0
We don't care about ILK-A and the old w/a notes may just confuse people, so get rid of them. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-12-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: s/DP_PLL_FREQ_160MHZ/DP_PLL_FREQ_162MHZ/Ville Syrjälä2-6/+6
The DP link frequency is 162MHz, not 160MHz. Rename the ILK eDP PLL defines to match. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-11-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-10drm/i915: Hide underruns from eDP PLL and port enable on ILKVille Syrjälä1-3/+31
We get underruns on the other pipe when enabling the CPU eDP PLL and port on ILK. Bspec knows about the PLL issue, and recommends doing a vblank wait just prior to enabling the PLL. That does seem to help, but unfortunately we get another underrun when actually enabling the CPU eDP port. Bspec doesn't mention that at all, and the same vblank wait trick doesn't appear to be effective there. Since I have no better clue how to deal with this, just hide the errors. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-10-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Disable FIFO underrun reporting around IBX transcoder B workaroundVille Syrjälä4-0/+42
Doing the IBX transcoder B workaround causes underruns on pipe/transcoder A. Just hide them by disabling underrun reporting for pipe A around the workaround. It might be possible to avoid the underruns by moving the workaround to be applied only when enabling pipe A. But I was too lazy to try it right now, and the current method has been proven to work, so didn't want to change it too hastily. Note that this can re-enable underrun reporting on pipe A if was already disabled due to a previous actual underrun. But that's OK, we may just get a second underrun report if another real underron occurrs on pipe A. v2: Note that pipe A underruns can get re-enabled due to this (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225802-11180-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Check for CPT and not !IBX in ironlake_disable_pch_transcoder()Ville Syrjälä1-1/+1
ironlake_enaable_pch_transcoder() checks for CPT to see if it should enable the timing override chicken bit, but ironlake_disable_pch_transcoder() checks for !IBX to see if it should clear the same bit. Change ironlake_disable_pch_transcoder() to check for CPT as well to keep the two sides consistent. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-8-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Check for FIFO underruns after modeset on IVB/HSW and CPT/PPTVille Syrjälä3-31/+103
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not always get an interrupt on a FIFO underrun. But we can always do an explicit check (like we do on GMCH platforms that have no underrun interrupt). v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Re-enable PCH FIO underrun reporting after pipe has been disabledVille Syrjälä1-0/+13
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for all the relevant underrun bits, so in order to keep the error interrupt enabled, we need to have underrun reporting enabled on all PCH transocders. Currently we leave the underrun reporting disabled when the pipe is off, which means we won't get any underrun interrupts when only a subset of the pipes are active. Fix the problem by re-enabling the underrun reporting after the pipe has been disabled. And to avoid the spurious underruns during pipe enable, disable the underrun reporting before embarking on the pipe enable sequence. So this way we have the error reporting disabled while running through the modeset sequence. v2: Re-enable PCH FIFO underrun reporting unconditionally on pre-HSW Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225691-10928-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Enable PCH FIFO underruns later on HSW+Ville Syrjälä1-7/+9
As we did for ILK/SNB/IVB, move the PCH FIFO underrun enable to happen after the encoder enable on HSW+. And again, for symmetry, move the the disable to happen before encoder disable. I've left out the vblank wait before the enable here because I don't know if it's needed or not. Actually I don't know if this entire change is needed as I don't have a HSW/BDW with VGA output. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-5-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVBVille Syrjälä1-4/+8
We get spurious PCH FIFO underruns if we enable the reporting too soon after enabling the crtc. Move it to be the last step, after the encoder enable. Additionally we need an extra vblank wait, otherwise we still get the underruns. Presumably the pipe/fdi isn't yet fully up and running otherwise. For symmetry, disable the PCH underrun reporting as the first thing, just before encoder disable, when shutting down the crtc. v2: Do the PCH underrun enable unconditionally (Jani, Daniel) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225627-10809-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-10drm/i915: Set sync polarity from adjusted mode for TRANS_DP_CTLVille Syrjälä1-2/+4
Rather than looking at crtc->mode (which is the user mode) dig up the sync polarity settings from the adjusted_mode when programming TRANS_DP_CTL on CPT/PPT. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: Don't use intel_pipe_to_cpu_transcoder() when there's a pipe config aroundVille Syrjälä1-5/+2
No point in doing the crtc->pipe->crtc->config->cpu_transcoder dance when we can just do crtc->config->cpu_transcoder. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2015-11-10drm/i915: remove in_dbg_master check from intel_fbc.cPaulo Zanoni1-6/+0
From our maintainer Daniel Vetter a few days ago: "Oh dear this is dead code. kdbg uses the fbcon, which always uses untiled, which means fbc will never be enabled. Also we have 0 users and 0 test coverage for kdbg on top of i915 (Jesse implemented it for fun years back). Imo just remove all this code." Adding to what Daniel said: for kgdboc's KMS support, intel_pipe_set_base_atomic() already manually disables FBC, so we won't do the in_dbg_master() check there. This is essentially a revert of: commit c924b934d0cd14a4559611da91f28f59acebe32a Author: Jason Wessel <jason.wessel@windriver.com> Date: Thu Aug 5 09:22:32 2010 -0500 i915: when kgdb is active display compression should be off Besides, it is not clear what is the exact problem caused by FBC, and why other features such as PSR, DRRS, IPS and RPM are not also checking for in_dbg_master(). IMHO we should either remove the code as suggested by Daniel or we add some nice comments explaining why is FBC so special. v2: Rebase due to new patch order. Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-13-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: clarify that checking the FB stride for CFB is intentionalPaulo Zanoni1-0/+1
Daniel was looking at this code and asked about whether fb->pitches[0] is correct, then he suggested we should a comment to make sure it is actually intentional. For more information on the CFB size calculation, please see the commit message of: commit c4ffd40908c30a33291227920e921f6b45b9e8f7 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Thu Oct 1 19:55:57 2015 -0300 drm/i915: fix CFB size calculation Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-12-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: remove too-frequent FBC debug messagePaulo Zanoni1-2/+0
If we run igt/kms_frontbuffer_tracking, this message will appear thousands of times, eating a significant part of our dmesg buffer. It's part of the expected FBC behavior, so let's just silence it. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-10-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: refactor FBC deactivation at initPaulo Zanoni2-5/+6
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the call from intel_display.c. Currently we only have the "enabled" software state, but later we'll have both "enabled" and "active", and we'll add assertions to them, so just calling intel_fbc_disable() from intel_modeset_init() won't work. It's better to make sure intel_fbc_init() already puts the hardware in the expected state, so we can put nice assertions in the other functions. v2: Keep/improve the comment (Chris). v3: Improve the commit message a little bit. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-9-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: don't disable_fbc() if FBC is already disabledPaulo Zanoni1-1/+2
If FBC is disabled we will still call intel_fbc_invalidate(), and as a result we may call intel_fbc_deactivate(), which will try to touch registers. I'm pretty sure I saw this happen on a runtime suspended device, and I'm almost sure I was running igt/pm_rpm. It produced the "you touched registers while the device is suspended" WARNs. But this was some time ago and I can't remember exactly which conditions were necessary to reproduce the problem. v2: Rebase to new series order. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-8-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: fix the __intel_fbc_update() commentsPaulo Zanoni1-24/+2
Don't try to list in comments the cases where we should enable or disable FBC: it varies a lot with the hardware generations and the code should be the documentation. Also notice that there's already a huge gap between the comments and what's in the code. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-7-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()Paulo Zanoni1-15/+15
This change was part of the commit that makes intel_fbc_update() receive an intel_crtc as argument instead of dev_priv, but since it was polluting the diff with too many chunks I decided to move it to its own commit. It seems that our developers are favoring having this instead of the old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the mentioned commit we'll get rid of the drm_crtc variable, so let's do an intermediate commit with the rename, so on the next commit we'll have just struct intel_crtc *crtc. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-6-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: extract crtc_is_valid() on the FBC codePaulo Zanoni1-5/+17
We're going to kill intel_fbc_find_crtc(), that's why a big part of the logic moved from intel_fbc_find_crtc() to crtc_is_valid(). v2: - Rebase due to pipe_a_only change. - Split the multiline conditional (Chris). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-5-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: remove unnecessary check for crtc->primary->fbPaulo Zanoni1-1/+1
We already check if the CRTC is visible, and it shouldn't be possible to have a visible CRTC without an FB. This was noticed by both Chris and Ville on different ocasions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-4-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: extract fbc_on_pipe_a_only()Paulo Zanoni1-6/+7
Make the code easier to read. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-3-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: rename intel_fbc_nuke to intel_fbc_recompressPaulo Zanoni1-3/+4
Although the term "nuke" is part of the FBC spec, it's not very intuitive, so let's rename it to make it easier for people that are not familiar with the spec. Requested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-2-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-10drm/i915: remove newline from a no_fbc_reason messagePaulo Zanoni1-1/+1
Newlines are not needed and they're not used by the other messages. I added the newline by mistake. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-14-git-send-email-paulo.r.zanoni@intel.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2015-11-09remove abs64()Andrew Morton2-4/+4
Switch everything to the new and more capable implementation of abs(). Mainly to give the new abs() a bit of a workout. Cc: Michal Nazarewicz <mina86@mina86.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-11-10drm/vc4: Add dependency on HAVE_DMA_ATTRS, and select DRM_GEM_CMA_HELPERGuenter Roeck1-1/+2
Avoid the following build errors, seen with m68k:allmodconfig and other architectures which do not support HAVE_DMA_ATTRS. ERROR: "drm_gem_cma_create" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_get_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_vm_ops" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_mmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_vunmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_import_sg_table" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_prime_vmap" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_dumb_map_offset" [drivers/gpu/drm/vc4/vc4.ko] undefined! ERROR: "drm_gem_cma_create" [drivers/gpu/drm/drm_kms_helper.ko] undefined! ERROR: "drm_gem_cma_describe" [drivers/gpu/drm/drm_kms_helper.ko] undefined! ERROR: "drm_gem_cma_free_object" [drivers/gpu/drm/drm_kms_helper.ko] undefined! Acked-by: Eric Anholt <eric@anholt.net> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-11-09drm/i915/bxt: Force port A DDI to use 4 lanesMatt Roper1-0/+14
The bspec indicates that DDI A using four lanes is the only valid configuration for Broxton (Broxton doesn't have a DDI E to split these lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always be set by the BIOS. However some BIOS versions seem to only be setting this bit if eDP is actually lit up at boot time; if the BIOS doesn't turn on the eDP panel because an external display is plugged in, then this bit is never properly initialized. The end result of this is that we wind up calculating a lower max data rate than we should and may wind up rejecting the native mode for panels that we should be able to drive. Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on in our driver's internal state if we recognize that we're running on BXT where it should have been on anyway. Cc: Imre Deak <imre.deak@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Tested-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446764012-27251-1-git-send-email-matthew.d.roper@intel.com
2015-11-09drm/i915: Print a debug message when exceeding dotclock limit on pre-gen4Ville Syrjälä1-8/+18
Currently there's no trace in dmesg when the gen2/3 dotclock checks reject the modeset. Add some to avoid further head scratching. While at it refactor the code a bit to look nicer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446241178-432-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
2015-11-09drm/i915: Avoid pointer arithmetic in calculating plane surface offsetMika Kuoppala3-11/+13
VMA offsets are 64 bits. Plane surface offsets are in ggtt and the hardware register to set this is thus 32 bits. Be explicit about these and convert carefully to from vma to final size. This will make sparse happy by not creating 32bit pointers out of 64bit vma offsets. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.com Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915: Add dmc firmware load state and version to error stateMika Kuoppala1-0/+11
We have had one case where buggy csr/dmc firmware version influenced gt side and caused a hang. Add dmc firmware loading state and version to error state. v2: - Rebased on top of Damien's patches - included fw load state v3: include dmc info only if platform supports it (Chris) v4: move *csr to branch scope (Chris) v5: remove dependency to csr_state Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446124879-22240-1-git-send-email-mika.kuoppala@intel.com Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915: Add csr programming registers to dmc debugfs entryMika Kuoppala3-16/+18
We check these to determine firmware loading status. Include them to help to debug causes of firmware loading fails. v2: Move all CSR specific registers to i915_reg.h (Ville) v3: Rebase v4: Rebase (RPM ref) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446220487-32691-1-git-send-email-mika.kuoppala@intel.com Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915/bxt: Expose DC5 entry countMika Kuoppala2-0/+4
For bxt CSR firmware exposes a count of dc5 entries. Expose it through debugs Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915/skl: Expose DC5/DC6 entry countsDamien Lespiau2-0/+15
The CSR firmware expose two counters, handy to check if we are indeed entering DC5/DC6. v2: Rebase v3: Take RPM ref before reading (Imre) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446220412-32574-1-git-send-email-mika.kuoppala@intel.com Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915/skl: Print the DMC firmware status in debugfsDamien Lespiau1-0/+27
Create a new debufs file for it, we'll have a few more things to add there. v2: Fix checkpatch warning about static const array v3: use named initializers (Ville) v4: strip out csr_state as it will be removed in future (Ville, Imre) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-3-git-send-email-mika.kuoppala@intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915/skl: Refuse to load outdated dmc firmwareMika Kuoppala1-10/+24
There is known issue on GT interrupt delivery with DC6 and firmwares <1.21. There is a suspicion that this causes spurious gpu hangs on driver init and with some workloads, as upgrading the firmware to 1.21 makes these problems disappear. As of now the current version included in distribution firmware packages is very like to be 1.19. Play it safe and refuse to load a firmware version that may affect gpu side stability. With < 1.23 there is a palette and dmc ram corruption issue so blacklist anything below that. v2: Refuse to load fw instead of notifying the user v3: Rebase on header version changes v4: Refuse to load anything less than 1.23 v5: Give enough information for user for finding correct fw (Chris) v6: better url and formatting (Chris) v7: move error log for each fail path (Mika) bail out earlier in load path (Imre) v8: Fix the version check (Imre) Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> References: https://01.org/linuxgraphics/downloads/skldmcver121 References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23 Testcase: igt/gem_exec_nop Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446220336-32392-1-git-send-email-mika.kuoppala@intel.com Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915/skl: Store and print the DMC firmware version we loadDamien Lespiau2-1/+13
That can be handy later on to tell which DMC firmware version the user has, by just looking at the dmesg. v2: use DRM_DEBUG_DRIVER (Chris) v3: use DRM_INFO (Marc Herbert) Cc: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-1-git-send-email-mika.kuoppala@intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Tested-by: Daniel Stone <daniels@collabora.com> # SKL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2015-11-09drm/i915: Fix failure paths around initial fbdev allocationTvrtko Ursulin1-8/+12
We had two failure modes here: 1. Deadlock in intelfb_alloc failure path where it calls drm_framebuffer_remove, which grabs the struct mutex and intelfb_create (caller of intelfb_alloc) was already holding it. 2. Deadlock in intelfb_create failure path where it calls drm_framebuffer_unreference, which grabs the struct mutex and intelfb_create was already holding it. [Daniel Vetter on why struct_mutex needs to be locked in the second half of intelfb_create: "The vma [for the fbdev] is pinned, the problem is that we re-lookup it a few times, which is racy. We should instead track the vma directly, but oh well we don't."] v2: * Reformat commit msg to 72 chars. (Lukas Wunner) * Add third failure mode. (Lukas Wunner) v5: * Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message. (Jani Nicula) v6: * In intelfb_alloc, if __intel_framebuffer_create failed, fb will be an ERR_PTR, thus not null. So in the failure path we need to check for IS_ERR_OR_NULL to avoid calling drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner) * Since this is init code a drm_framebuffer_unreference should be all we need. drm_framebuffer_remove is for framebuffers that userspace has created - and is getting somewhat defeatured. (Daniel Vetter) v7: * Clarify why struct_mutex needs to be locked in the second half of intelfb_create. (Daniel Vetter) Fixes: 60a5ca015ffd ("drm/i915: Add locking around framebuffer_references--") Reported-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> [Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2] Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-09drm/i915: Fix double unref in intelfb_alloc failure pathLukas Wunner1-3/+2
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails, the bo is unrefed twice: By drm_framebuffer_remove() and once more by drm_gem_object_unreference(). Fix it. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/cd7b33330621a350b0159ec5e098297b139cfaf7.1446892879.git.lukas@wunner.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-09drm/i915: On fb alloc failure, unref gem object where it gets refedLukas Wunner1-7/+14
Currently when allocating a framebuffer fails, the gem object gets unrefed at the bottom of the call stack in __intel_framebuffer_create, not where it gets refed, which is in intel_framebuffer_create_for_mode (via i915_gem_alloc_object) and in intel_user_framebuffer_create (via drm_gem_object_lookup). This invites mistakes: __intel_framebuffer_create is also called from intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref was introduced there with a8bb6818270c ("drm/i915: Fix error path leak in fbdev fb allocation"). As suggested by Ville Syrjälä, fix the double unref and improve code clarity by moving the unref away from __intel_framebuffer_create to where the gem object gets refed. Based on Tvrtko Ursulin's original v2. v3: On fb alloc failure, unref gem object where it gets refed, fix double unref in separate commit (Ville Syrjälä) v4: Lock struct_mutex on unref (Chris Wilson) v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message (Jani Nicula) Tested-by: Pierre Moreau <pierre.morrow@free.fr> [MBP 5,3 2009 nvidia MCP79 + G96 pre-retina] Tested-by: Paul Hordiienko <pvt.gord@gmail.com> [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: William Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: Lukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107 retina] Fixes: a8bb6818270c ("drm/i915: Fix error path leak in fbdev fb allocation") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.de Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-11-07Merge branch 'akpm' (patches from Andrew)Linus Torvalds3-45/+3
Merge second patch-bomb from Andrew Morton: - most of the rest of MM - procfs - lib/ updates - printk updates - bitops infrastructure tweaks - checkpatch updates - nilfs2 update - signals - various other misc bits: coredump, seqfile, kexec, pidns, zlib, ipc, dma-debug, dma-mapping, ... * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (102 commits) ipc,msg: drop dst nil validation in copy_msg include/linux/zutil.h: fix usage example of zlib_adler32() panic: release stale console lock to always get the logbuf printed out dma-debug: check nents in dma_sync_sg* dma-mapping: tidy up dma_parms default handling pidns: fix set/getpriority and ioprio_set/get in PRIO_USER mode kexec: use file name as the output message prefix fs, seqfile: always allow oom killer seq_file: reuse string_escape_str() fs/seq_file: use seq_* helpers in seq_hex_dump() coredump: change zap_threads() and zap_process() to use for_each_thread() coredump: ensure all coredumping tasks have SIGNAL_GROUP_COREDUMP signal: remove jffs2_garbage_collect_thread()->allow_signal(SIGCONT) signal: introduce kernel_signal_stop() to fix jffs2_garbage_collect_thread() signal: turn dequeue_signal_lock() into kernel_dequeue_signal() signals: kill block_all_signals() and unblock_all_signals() nilfs2: fix gcc uninitialized-variable warnings in powerpc build nilfs2: fix gcc unused-but-set-variable warnings MAINTAINERS: nilfs2: add header file for tracing nilfs2: add tracepoints for analyzing reading and writing metadata files ...
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.