aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2015-06-18drm/radeon: Add RADEON_INFO_VA_UNMAP_WORKING queryMichel Dänzer1-0/+3
This tells userspace that it's safe to use the RADEON_VA_UNMAP operation of the DRM_RADEON_GEM_VA ioctl. Cc: stable@vger.kernel.org (NOTE: Backporting this commit requires at least backports of commits 26d4d129b6042197b4cbc8341c0618f99231af2f, 48afbd70ac7b6aa62e8d452091023941d8085f8a and c29c0876ec05d51a93508a39b90b92c29ba6423d as well, otherwise using RADEON_VA_UNMAP runs into trouble) Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2015-06-18drm/i915: Reset request handling for gen8+Mika Kuoppala2-1/+45
In order for gen8+ hardware to guarantee that no context switch takes place during engine reset and that current context is properly saved, the driver needs to notify and query hw before commencing with reset. There are gpu hangs where the engine gets so stuck that it never will report to be ready for reset. We could proceed with reset anyway, but with some hangs with skl, the forced gpu reset will result in a system hang. By inspecting the unreadiness for reset seems to correlate with the probable system hang. We will only proceed with reset if all engines report that they are ready for reset. If root cause for system hang is found and can be worked around with another means, we can reconsider if we can reinstate full reset for unreadiness case. v2: -EIO, Recovery, gen8 (Chris, Tomas, Daniel) v3: updated commit msg v4: timeout_ms, simpler error path (Chris) References: https://bugs.freedesktop.org/show_bug.cgi?id=89959 References: https://bugs.freedesktop.org/show_bug.cgi?id=90854 Testcase: igt/gem_concurrent_blit/prw-blt-overwrite-source-read-rcs-forked Testcase: igt/gem_concurrent_blit/gtt-blt-overwrite-source-read-rcs-forked Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tomas Elf <tomas.elf@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18GPU: ipu: Fix race in installing IPU chained IRQ handlerRussell King1-8/+5
The IPU code was installing its chained interrupt handler (which enables the interrupt) before it was setting its data, which provokes an oops on kexec. Fix this by converting to irq_set_chained_handler_and_data(). [drm] Initialized drm 1.1.0 20060810 imx-drm display-subsystem: parent device of /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@1 is not available imx-drm display-subsystem: parent device of /soc/aips-bus@02000000/ldb@020e0008/lvds-channel@1 is not available Unable to handle kernel NULL pointer dereference at virtual address 00000070 pgd = c0004000 [00000070] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.1.0-rc6+ #1693 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) task: d74c0000 ti: d74aa000 task.ti: d74aa000 PC is at ipu_irq_handle+0x28/0xd8 LR is at ipu_irq_handler+0x6c/0xc0 pc : [<c03c56d8>] lr : [<c03c58a4>] psr: 200001d3 sp : d74abbd0 ip : d74abc00 fp : d74abbfc r10: 000001e0 r9 : c0085154 r8 : 00000009 r7 : 00000000 r6 : 00000000 r5 : d74abc04 r4 : c0a6b6a8 r3 : 00000000 r2 : 00000009 r1 : d74abc04 r0 : 00000000 Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 10c5387d Table: 10004059 DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xd74aa210) Stack: (0xd74abbd0 to 0xd74ac000) Backtrace: [<c03c56b0>] (ipu_irq_handle) from [<c03c58a4>] (ipu_irq_handler+0x6c/0xc0) [<c03c5838>] (ipu_irq_handler) from [<c0080154>] (generic_handle_irq+0x28/0x38) [<c008012c>] (generic_handle_irq) from [<c0080288>] (__handle_domain_irq+0x5c/0xb8) [<c008022c>] (__handle_domain_irq) from [<c0009428>] (gic_handle_irq+0x28/0x68) [<c0009400>] (gic_handle_irq) from [<c0013dc4>] (__irq_svc+0x44/0x5c) [<c07638fc>] (_raw_spin_unlock_irqrestore) from [<c00803bc>] (__irq_put_desc_unlock+0x1c/0x40) [<c00803a0>] (__irq_put_desc_unlock) from [<c00841f4>] (__irq_set_handler+0x54/0x5c) [<c00841a0>] (__irq_set_handler) from [<c03c5f48>] (ipu_probe+0x29c/0x708) [<c03c5cac>] (ipu_probe) from [<c03d3848>] (platform_drv_probe+0x50/0xac) [<c03d37f8>] (platform_drv_probe) from [<c03d1f3c>] (driver_probe_device+0x1d4/0x278) Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Hans Ulli Kroll <ulli.kroll@googlemail.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Lee Jones <lee.jones@linaro.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/E1Z4z02-0002SI-Br@rmk-PC.arm.linux.org.uk Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-06-18drm/i915/bxt: eDP Panel Power sequencingVandana Kannan2-17/+78
Changes for BXT - added a IS_BROXTON check to use the macro related to PPS registers for BXT. BXT does not have PP_DIV register. Making changes to handle this. Second set of PPS registers have been defined but will be used when VBT provides a selection between the 2 sets of registers. v2: [Jani] Added 2nd set of PPS registers and the macro Jani's review comments - remove reference in i915_suspend.c - Use BXT PP macro Squashing all PPS related patches into one. v3: Jani's review comments addressed - Use pp_ctl instead of pp - ironlake_get_pp_control() is not required for BXT - correct the use of && in the print statement - drop the shift in the print statement v4: Jani's comments - modify ironlake_get_pp_control() - dont set unlock key for bxt v5: Sonika's comments addressed - check alignment - move pp_ctrl_reg write (after ironlake_get_pp_control()) to !IS_BROXTON case. - check before subtracting 1 for t11_t12 Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18Merge branch 'virtio-gpu-drm-next' of git://git.kraxel.org/linux into drm-nextDave Airlie4-21/+38
fixes and virtio-vga support. * 'virtio-gpu-drm-next' of git://git.kraxel.org/linux: virtio-gpu: add locking for vbuf pool drm/virtgpu: initialise fbdev after getting initial display info Add virtio-vga bits.
2015-06-18Merge tag 'drm/panel/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-nextDave Airlie7-44/+78
drm/panel: Changes for v4.2-rc1 This contains fixes for the long-standing build issues that some of the bridge drivers were exposing. Other than that it's mostly cleanup and a couple of new simple panels that are supported. * tag 'drm/panel/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/panel: simple: Add bus format for HannStar HSD100PXN1 drm/panel: simple: Add display timing for HannStar HSD100PXN1 drm/panel: ld9040: Remove useless padding drm/panel: Constify OF match tables drm/bridge: Remove stale ptn3460.h include drm/bridge: ps8622: Include linux/gpio/consumer.h drm/bridge: ptn3460: Include linux/gpio/consumer.h drm/bridge: dw-hdmi: Return number of EDID modes drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel drm/bridge: ptn3460: Pass flags to devm_gpiod_get() drm/bridge: ps8622: Pass flags to devm_gpiod_get() drm/bridge: ptn3460: Fix I2C ID table to match the reported modalias drm/bridge: dw-hdmi: Staticize dw_hdmi_bridge_funcs
2015-06-18Merge tag 'drm/tegra/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-nextDave Airlie3-40/+36
drm/tegra: Changes for v4.2-rc1 This contains a couple of mostly fixes for issues that have crept up in recent versions of linux-next. One issue is that DP AUX transactions of more than 4 bytes will access the wrong FIFO registers and hence become corrupt. Another fix is required to restore functionality of Tegra20 if using the GART. The current code expects the IOMMU aperture to be the complete 4 GiB address space, whereas the GART on Tegra20 only provides a 128 MiB aperture. One more issue with IOMMU support is that on 64-bit ARM, swiotlb is the default IOMMU implementation backing the DMA API. A side-effect of that is that when dma_map_sg() is called to flush caches (yes, this is a bit of a hack, but ARM does not provide a better API), swiotlb will immediately run out of memory because its bounce buffer is too small to make a framebuffer. Finally I've included a mostly cosmetic fix that stores register values in u32 rather than unsigned long to avoid sign-extension issues on 64- bit ARM. This is only a precaution since it hasn't caused any issues (yet). * tag 'drm/tegra/for-4.2-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: dpaux: Registers are 32-bit drm/tegra: gem: Flush pages after allocation drm/tegra: gem: Take into account IOMMU aperture drm/tegra: dpaux: Fix transfers larger than 4 bytes
2015-06-18Merge branch 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev into drm-nextDave Airlie5-22/+45
rcar-du fixes * 'drm/next/du' of git://linuxtv.org/pinchartl/fbdev: drm: rcar-du: Use the drm atomic state duplication helpers for planes drm: rcar-du: Clean up planes in the error paths of .atomic_commit() drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0 drm: rcar-du: Clarify error message when encoder initialization fails drm: rcar-du: Fix crash with groups that have less than 9 planes drm: rcar-du: Disable all planes when stopping the CRTC drm: rcar-du: Print the error value when DRM/KMS init fails
2015-06-17drm/i915: Use helper to set CRTC state's modeMatt Roper1-2/+3
We need to call drm_atomic_set_mode_for_crtc() rather than copying the mode in manually. As of commit commit 99cf4a29fa24461bbfe22125967188a18383eb5c Author: Daniel Stone <daniels@collabora.com> Date: Mon May 25 19:11:51 2015 +0100 drm/atomic: Add current-mode blob to CRTC state the helper now also takes care of setting up the mode property blob for us; if we don't use the helper and never setup the mode blob, this will also trigger a failure in drm_atomic_crtc_check() when we have the DRIVER_ATOMIC flag set (i.e., when using the nuclear pageflip support via i915.nuclear_pageflip kernel command line parameter). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-17drm/i915: Don't set enabled value of all CRTCs when restoring the modeAnder Conselvan de Oliveira1-17/+10
The code in intel_crtc_restore_mode() sets the enabled value of all the CRTCs when restoring the mode after a suspend/resume cycle. When more than one CRTC is enabled, that causes drm_atomic_helper_check_modeset() to fail if there is more than one pipe enabled, since all but one CRTC has valid connector data. Instead, set only the enabled value for the CRTC passed as an argument. v2: Don't leak atomic state. (Matt) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90468 References: https://bugs.freedesktop.org/show_bug.cgi?id=90396 Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
2015-06-17drm/i915: Don't update staged config during force restore modesetsAnder Conselvan de Oliveira1-5/+3
The force restore path relies on the staged config to preserve the configuration used before a suspend/resume cycle. The update done to it in intel_modeset_fixup_state() would cause that information to be lost after the first modeset, making it impossible to restore the modes for pipes B and C. References: https://bugs.freedesktop.org/show_bug.cgi?id=90468 Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-17drm/i915: Don't check modeset state in the hw state force restore pathAnder Conselvan de Oliveira1-9/+12
Since the force restore logic will restore the CRTCs state one at a time, it is possible that the state will be inconsistent until the whole operation finishes. A call to intel_modeset_check_state() is done once it's over, so don't check the state multiple times in between. This regression was introduced in: commit 7f27126ea3db6ade886f18fd39caf0ff0cd1d37f Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Nov 5 14:26:06 2014 -0800 drm/i915: factor out compute_config from __intel_set_mode v3 v2: Rename check parameter to force_restore. (Matt) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=94431 Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-16drivers/gpu: include <module.h> for modular rockchip codePaul Gortmaker2-0/+2
These files are built off of a tristate Kconfig option and also contain modular function calls so they should explicitly include module.h to avoid compile breakage during header shuffles done in the future. Cc: David Airlie <airlied@linux.ie> Cc: Mark Yao <mark.yao@rock-chips.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
2015-06-16drm/amdkfd: fix some range checks in address watch ioctlDan Carpenter1-3/+3
buf_size_in_bytes must be large enough to hold ->num_watch_points and watch_mode so I have added a sizeof(int) * 2 to the minimum size. Also we have to subtract sizeof(*args) from the max args_idx limit so that it matches the allocation. Also I changed a > to >= for the last compare. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2015-06-16drm: rcar-du: Use the drm atomic state duplication helpers for planesLaurent Pinchart1-5/+5
Ensure that the duplicate and destroy plane state operations will always be in sync with the DRM core implementation of the plane state by using the __drm_atomic_helper_plane_duplicate_state() and __drm_atomic_helper_plane_destroy_state() functions designed especially for this purpose. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-16drm: rcar-du: Clean up planes in the error paths of .atomic_commit()Laurent Pinchart1-3/+9
When the .atomic_commit() handler fails, clean up planes previoulsy prepared by drm_atomic_helper_prepare_planes() with a call to drm_atomic_helper_cleanup_planes(). Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
2015-06-16drm: rcar-du: Convert rcar_du_encoders_init_one() return value to 0/<0Laurent Pinchart1-5/+5
The function returns 1 on success, and either 0 or a negative error code on failure. As the 0 and negative values don't need to be differentiated by the caller, convert it to the usual scheme of returning 0 on success and a negative error code on failure. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2015-06-16drm: rcar-du: Clarify error message when encoder initialization failsLaurent Pinchart1-2/+5
A failure to initialize an encoder currently prints an error message in the kernel log without mentioning which encoder failed to initialize. To help debugging initialization issues print the encoder DT node name. This requires moving the error message to the rcar_du_encoders_init_one function and refactoring it slightly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2015-06-16drm: rcar-du: Fix crash with groups that have less than 9 planesLaurent Pinchart4-6/+7
Commit 917de180379d ("drm: rcar-du: Implement universal plane support") made the number of planes per group dynamic, but didn't update all loops over the planes array, resulting in out-of-bound accesses on DU instances that have an odd number of CRTCs (such as the R8A7790). Fix it. Fixes: 917de180379d ("drm: rcar-du: Implement universal plane support") Cc: stable@vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2015-06-16drm: rcar-du: Disable all planes when stopping the CRTCLaurent Pinchart1-0/+13
The DSnPR plane configuration registers are updated on vblank, and no vblank will occur once the CRTC is stopped. We thus can't only disable planes right before starting the CRTC as it would start scanning out immediately from old frame buffers until the next vblank. Fix the problem by disabling all planes when stopping the CRTC and wait for the change to take effect. This increases the CRTC stop delay, especially when multiple CRTCs are stopped in one operation as we now wait for one vblank per CRTC. Whether this can be improved needs to be researched. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2015-06-16drm: rcar-du: Print the error value when DRM/KMS init failsLaurent Pinchart1-1/+1
This helps debugging probe failures. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
2015-06-16virtio-gpu: add locking for vbuf poolDave Airlie2-0/+8
Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-06-16drm/virtgpu: initialise fbdev after getting initial display infoDave Airlie3-1/+6
This should avoid issues with the fbdev path trying to render before we've gotten the display info. Signed-off-by: Dave Airlie <airlied@redhat.com> [ kraxel: wait for display-info reply ] Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2015-06-16Add virtio-vga bits.Gerd Hoffmann1-20/+24
2015-06-16drm/radeon: remove obsolete kfd_bo from radeon_deviceOded Gabbay1-1/+0
Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com>
2015-06-16Merge tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-nextDave Airlie13-869/+660
omapdrm atomic modesetting support Atomic modesetting support for omapdrm. " we've had issues with omapdrm for years, which we've not been able to fix properly (like warnings/crashes when unloading modules, page-flips tearing, race issues with fbs). All those problems seem to be gone after this rewrite of omapdrm for atomic modesetting, and the resulting code is much cleaner and more maintainable." * tag 'omapdrm-4.2-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux: (43 commits) drm: omapdrm: new vblank and event handling drm: omapdrm: merge omap_crtc_flush and omap_crtc_atomic_flush drm: omapdrm: add lock for fb pinning drm: omapdrm: if omap_plane_atomic_update fails, disable plane drm: omapdrm: inline omap_plane_setup into update/disable drm: omapdrm: omap_plane_setup() cannot fail, use WARN drm: omapdrm: Don't setup planes manually from CRTC .enable()/.disable() drm: omapdrm: Don't flush CRTC when enabling or disabling it drm: omapdrm: Move encoder setup to encoder operations drm: omapdrm: Simplify DSS power management drm: omapdrm: Remove nested PM get/sync when configuring encoders drm: omapdrm: Support unlinking page flip events prematurely drm: omapdrm: omap_crtc_flush() isn't called with modeset locked drm: omapdrm: Don't get/put dispc in omap_crtc_flush() drm: omapdrm: Make the omap_crtc_flush function static drm: omapdrm: Remove omap_plane enabled field drm: omapdrm: Remove omap_crtc enabled field drm: omapdrm: Move crtc info out of the crtc structure drm: omapdrm: Move plane info and win out of the plane structure drm: omapdrm: Switch crtc and plane set_property to atomic helpers ...
2015-06-16drm/mgag200: Reject non-character-cell-aligned mode widthsAdam Jackson1-0/+5
Turns out 1366x768 does not in fact work on this hardware. Signed-off-by: Adam Jackson <ajax@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2015-06-15drm/i915: Remove more ilk rc6 remnantsDaniel Vetter1-10/+2
Leftover from the big purge commit a561165493e5fec2f74bd3ae0577ed659e44ab7f Author: John Harrison <John.C.Harrison@Intel.com> Date: Thu Mar 5 14:03:03 2015 +0000 drm/i915: Remove ironlake rc6 support Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Rob Clark <robdclark@gmail.com> Reported-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-06-15drm/i915: Limit CHV max cdclkMika Kahola1-0/+2
Limit CHV maximum cdclk to 320MHz. v2: Rebase to the latest v3: Clean up of if-else tree Signed-off-by: Mika Kahola <mika.kahola@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: don't set the FBC plane select bits on HSW+Paulo Zanoni1-1/+4
This commit is just to make the intentions explicit: on HSW+ these bits are MBZ, but since we only support plane A and the macro evaluates to zero when plane A is the parameter, we're not fixing any bug. v2: - Remove useless extra blank like (Chris). - Init dpfc_ctl in another place (Chris). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: unify no_fbc_reason message printingPaulo Zanoni3-69/+51
This commit has two main advantages: simplify intel_fbc_update() and deduplicate the strings. v2: - Rebase due to changes on P1. - set_no_fbc_reason() can now return void (Chris). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: add FBC_ROTATION to enum no_fbc_reasonPaulo Zanoni3-1/+5
Because we're currently using FBC_UNSUPPORTED_MODE for two different cases. This commit will also allow us to write the next one without hiding information from the user. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: print FBC compression status on debugfsPaulo Zanoni2-0/+8
We already had a few bugs in the past where FBC was compressing nothing when it was enabled, which makes the feature quite useless. Add this information to debugfs so the test suites can check for regressions in this piece of the code. Our igt/tests/kms_frontbuffer_tracking already has support for this message. v2: - Remove pointless VLV check (Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Drop the 64k linear scanout alignment on gen2/3Ville Syrjälä1-1/+1
The docs don't support the 64k linear scanout alignment we impose on gen2/3. And it really makes no sense since we have no DSPSURF register, so the only thing that the hardware will see is the linear offset which will be just pixel aligned anyway. There is one case where 64k comes into the picture, and that's FBC. The start of the line length buffer corresponds to a 64k aligned address of the uncompressed framebuffer. So if the uncompressed fb is not 64k aligned, the first actually used entry in the line length buffer will not be byte 0. There are 32 extra entries in the line length buffer to account for this extra alignment so we shouldn't have to worry about it when mapping the uncompressed fb to the GTT. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Align DSPSURF to 128k on VLV/CHVVille Syrjälä1-1/+2
VLV/CHV have problems with 4k aligned linear scanout buffers. The VLV docs got updated at some point to say that we need to align them to 128k, just like we do on gen4. So far I've seen the problem manifest when the stride is an odd multiple of 512 bytes, and the surface address meets the following pattern '(addr & 0xf000) == 0x1000' (also == 0x2000 is problematic on VLV). The result is a starcase effect (so some pages get dropped maybe?), with a few pages here and there clearly getting scannout out at the wrong position. I've not actually been able to reproduce this problem on gen4, so it's not clear of the issue is any way related to the 128k restrictions supposedly inherited from gen4. But let's hope the 128k alignment is sufficient to hide it all. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Actually respect DSPSURF alignment restrictionsVille Syrjälä3-18/+31
Currently intel_gen4_compute_page_offset() simply picks the closest page boundary below the linear offset. That however may not be suitably aligned to satisfy any hardware specific restrictions. So let's make sure the page boundary we choose is properly aligned. Also to play it a bit safer lets split the remaining linear offset into x and y values instead of just x. This should make no difference for most platforms since we convert the x and y offsets back into a linear offset before feeding them to the hardware. HSW+ are different however and use x and y offsets even with linear buffers, so they might have trouble if either the x or y get too big. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Delete duplicate #defines added for DCxChandra Konduru1-6/+0
Delete the duplicate #defines introduced by: commit 6b457d31ea0465fcadcf6d5044f5f71398954727 Author: A.Sunil Kamath <sunil.kamath@intel.com> Date: Thu Apr 16 14:22:09 2015 +0530 drm/i915/skl: Implement enable/disable for Display C5 state. Signed-off-by: Chandra Konduru <chandra.konduru@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Restarting the Idleness DRRS in drrs_flushRamalingam C1-10/+20
Corrected the documentation on the intel_edp_drrs_flush and intel_edp_drrs_invalidate. And accordingly edp_drrs_flush function is modified to restart the idleness detection after upclocking. v2: Update kerneldoc Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (v1) Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15Merge branch 'topic/atomic-conversion' into drm-intel-next-queuedDaniel Vetter7-583/+513
The i915 atomic conversion is a real beast and it's not getting easier wrangling in a separate branch. I'm might be regretting this, but right after vacation nothing can burst my little bubble here! Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-06-15drm/i915: Report to userspace if we have a (presumed) working GPU resetChris Wilson3-6/+28
In igt, we want to test handling of GPU hangs, both for recovery purposes and for reporting. However, we don't want to inject a genuine GPU hang onto a machine that cannot recover and so be permenantly wedged. Rather than embed heuristics into igt, have the kernel report exactly when it expects the GPU reset to work. This can also be usefully extended in future to indicate different levels of fine-grained resets. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tim Gore <tim.gore@intel.com> Cc: Tomas Elf <tomas.elf@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Fix build without CONFIG_PMChris Wilson1-0/+4
drivers/gpu/drm/i915/i915_debugfs.c: In function ‘i915_runtime_pm_status’: drivers/gpu/drm/i915/i915_debugfs.c:2528:34: error: ‘struct dev_pm_info’ has no member named ‘usage_count’ atomic_read(&dev->dev->power.usage_count)); Regression from commit a6aaec8be22652a808d6e316d4a92e58cb75e986 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Thu Jun 4 18:23:58 2015 +0100 drm/i915: Add runtime PM's usage_count in i915_runtime_pm_status Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.Francisco Jerez1-0/+7
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be set because of security-sensitive bits we don't want userspace to mess with. On HSW hardware the whitelisted bits control whether atomic read-modify-write operations are performed on L3 or on GTI, and when set to L3 (which can be 10x-30x better performing than on GTI, depending on the application) require great care to avoid a system hang, so we currently program them to be handled on GTI by default. Beignet can immediately start taking advantage of this change to enable L3 atomics. Mesa should eventually switch to L3 atomics too, but a number of non-trivial changes are still required so it will continue using GTI atomics for now. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-15drm/i915: Extend the parser to check register writes against a mask/value pair.Francisco Jerez2-47/+96
In some cases it might be unnecessary or dangerous to give userspace the right to write arbitrary values to some register, even though it might be desirable to give it control of some of its bits. This patch extends the register whitelist entries to contain a mask/value pair in addition to the register offset. For registers with non-zero mask, any LRM writes and LRI writes where the bits of the immediate given by the mask don't match the specified value will be rejected. This will be used in my next patch to grant userspace partial write access to some sensitive registers. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-15drm/i915: Fix command parser to validate multiple register access with the same command.Francisco Jerez2-31/+48
Until now the software command checker assumed that commands could read or write at most a single register per packet. This is not necessarily the case, MI_LOAD_REGISTER_IMM expects a variable-length list of offset/value pairs and writes them in sequence. The previous code would only check whether the first entry was valid, effectively allowing userspace to write unrestricted registers of the MMIO space by sending a multi-register write with a legal first register, with potential security implications on Gen6 and 7 hardware. Fix it by extending the drm_i915_cmd_descriptor table to represent multi-register access and making validate_cmd() iterate for all register offsets present in the command packet. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-15drm/i915: Make sure our labels start at column 0Damien Lespiau2-3/+3
I noticed one of those and it turned out we have a few lingering around. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915/skl: Add debug messages at the start/end of DMC firmware loadingDamien Lespiau1-0/+3
It's handy to have debug message for the "big" events and this one qualifies IMHO. Also helpful to see what's happening while we're loading the firwmare and how much time it takes. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Remove unnecessary () used with WARN()Damien Lespiau1-1/+2
In Linux, macros are usually well done and protect their arguments properly, even avoiding multiple evaluations of the parameters. Extra () are really not needed. Cc: Suketu Shah <suketu.j.shah@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15Revert "drm/i915: Don't skip request retirement if the active list is empty"Jani Nikula1-0/+3
This reverts commit 0aedb1626566efd72b369c01992ee7413c82a0c5. I messed things up while applying [1] to drm-intel-fixes. Rectify. [1] http://mid.gmane.org/1432827156-9605-1-git-send-email-ville.syrjala@linux.intel.com Fixes: 0aedb1626566 ("drm/i915: Don't skip request retirement if the active list is empty") Cc: stable@vger.kernel.org Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-06-15drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.Francisco Jerez1-0/+7
Only bit 27 of SCRATCH1 and bit 6 of ROW_CHICKEN3 are allowed to be set because of security-sensitive bits we don't want userspace to mess with. On HSW hardware the whitelisted bits control whether atomic read-modify-write operations are performed on L3 or on GTI, and when set to L3 (which can be 10x-30x better performing than on GTI, depending on the application) require great care to avoid a system hang, so we currently program them to be handled on GTI by default. Beignet can immediately start taking advantage of this change to enable L3 atomics. Mesa should eventually switch to L3 atomics too, but a number of non-trivial changes are still required so it will continue using GTI atomics for now. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-15drm/i915: Extend the parser to check register writes against a mask/value pair.Francisco Jerez2-47/+96
In some cases it might be unnecessary or dangerous to give userspace the right to write arbitrary values to some register, even though it might be desirable to give it control of some of its bits. This patch extends the register whitelist entries to contain a mask/value pair in addition to the register offset. For registers with non-zero mask, any LRM writes and LRI writes where the bits of the immediate given by the mask don't match the specified value will be rejected. This will be used in my next patch to grant userspace partial write access to some sensitive registers. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.