summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2014-11-20drm/radeon: Use cursor_set2 hook for enabling / disabling the HW cursorMichel Dänzer
The cursor_set2 hook provides the cursor hotspot position within the cursor image. When the hotspot position changes, we can adjust the cursor position such that the hotspot doesn't move on the screen. This prevents the cursor from appearing to intermittently jump around on the screen when the position of the hotspot within the cursor image changes. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2014-11-20drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersaveImre Deak
This function can be called now with i915 interrupts enabled, so the corresponding WARN is incorrect, remove it. I think this was spotted by Paulo during his review, but since I already removed the same WARN from intel_suspend_gt_powersave() I missed then his point. Spotted-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Use ggtt error obj capture helper for gen8 semaphoresDaniel Vetter
Spotted while reading and trying to understand how our error capture code deals with full ppgtt. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20drm/i915: vlv: increase timeout when setting idle GPU freqImre Deak
I saw punit timeouts in vlv_set_rps_idle() while running various subtests of pm_rpm. Increasing the timeout to 100ms got rid of the issue. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: vlv: fix cdclk setting during modeset while suspendedImre Deak
Currently after doing DPMS-OFF on all outputs CDCLK won't be set to its minimum value as it should. A subsequent modeset to turn off all outputs will thus run with all power domains disabled, and notice that it needs to change CDCLK to its minimum value. Since the power domains are disabled this will emit a register-access-while-suspended WARN and fail to set the minimum freq. The proper solution for this is to set the minimum frequency during DPMS-OFF. That needs a bigger rework that would take into account the user DPMS setting too during the calculation of the new modesetting configuration. Until that's done this stop-gap solution gets the PIPE-A power domain during setting the CDCLK; this domain covers the HW blocks needed for this. Idea to use PIPE-A domain from Ville. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Dump hdmi pipe_config stateDaniel Vetter
Makes it easier to debug infoframe mismatches. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20drm/i915: Gen9 shadowed registersZhe Wang
For MMIO registers which are shadowed, force wake is not needed to write to these registers. v2: Rebase on top of nightly (Damien) v3: Rebase on top of "Gen9 multiple-engine forcewake" changes v4: (Mika, Bob, done by Damien) - Reorder the shadowed registers by popularity Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915/skl: Gen9 multi-engine forcewakeZhe Wang
Enable multi-engine forcewake for Gen9. v2: (Damien) - Rebase on top of nightly - Move the register range definitions to intel_uncore.c - Whitespace fixes v3: (Addressing Mika's comment, done by Damien) - Use REG_RANGE() (introduced after the patch was written) - Add a SKL_NEEDS_FORCE_WAKE() macro that gets rid of a useless comparison to FORCEWAKE (reg 0xa18c is not used on SKL) v4: (Damien) - Use newly introduced ASSIGN_READ/WRITE_MMIO_VFUNCS() macros Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20Replace mentions of "list_struct" to "list_head"Andrey Utkin
There's no such thing as "list_struct". Signed-off-by: Andrey Utkin <andrey.krieger.utkin@gmail.com> Acked-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2014-11-20drm/i915: Read power well status before other registers for drpc infoVille Syrjälä
Trying to read the status of the power wells right after taking forcewake for the other register reads makes little sense. Most of the time the power wells will still be up due to the recent forcewake. Instead do the power well status read first, and only then read the register needing forcewake. This way the reported power well status can actually reflect what's going on in the system. Cc: Deepak S <deepak.s@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Pin tiled objects for L-shaped configsDaniel Vetter
Let's just throw in the towel on this one and take the cheap way out. Based on a patch from Chris Wilson, but checking for a different bit. Chris' patch checked for even bank layout, this one here for a magic bit. Given the evidence we've gathered (not much) both work I think, but checking for the magic bit might be more accurate. Anyway, works on my gm45 here. For paranoi restrict to gen4 (and mobile), since we've only ever seen this on gm45 and i965gm. Also add some debugfs output so that we can skip the tiled swapping tests properly in these cases. v2: Clean up the quirk'ed pin count in free_object to avoid upsetting the WARN_ON. Spotted by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=28813 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45092 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Update ring freq for full gpu freq rangeTom O'Rourke
In __gen6_update_ring_freq, use the full range of possible gpu frequencies from max_freq to min_freq. The actual gpu frequency could be outside the range from max_freq_softlimit to min_freq_softlimit due to power/thermal constraints. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: change initial rps frequency for gen8Tom O'Rourke
In gen8_enable_rps, change the initial rps setting to the min_freq_softlimit (same as gen6_enable_rps). Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Keep min freq above floor on HSW/BDWTom O'Rourke
Set the min_freq_softlimit to max(RPe, 450MHz). Setting a floor can ensure a minimum experience level. The 450MHz value came from a power and performance study of various types of workloads (3D, Media, GPGPU, idle, etc). v2: rebased Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Use efficient frequency for HSW/BDWTom O'Rourke
Added gen6_init_rps_frequencies() to initialize the rps frequency values. This function replaces parse_rp_state_cap(). In addition to reading RPn, RP0, and RP1 from RP_STATE_CAP register, the new function reads efficient frequency (aka RPe) from pcode for Haswell and Broadwell and sets the turbo softlimits. The turbo minimum frequency softlimit is set to RPe for Haswell and Broadwell and to RPn otherwise. For RPe, the efficiency is based on the frequency/power ratio (MHz/W); this is considering GT power and not package power. The efficent frequency is the highest frequency for which the frequency/power ratio is within some threshold of the highest frequency/power ratio. A fixed decrease in frequency results in smaller decrease in power at frequencies less than RPe than at frequencies above RPe. v2: Following suggestions from Chris Wilson and Daniel Vetter to extend and rename parse_rp_state_cap and to open-code a poorly named function. Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Remove unused variables.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-20drm/i915: Can i915_gem_init_ioctlDaniel Vetter
Found one more! With this we can clear up the ggtt init code a bit, yay! Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20drm/i915: Sanitize ->lastcloseDaniel Vetter
With this all the ums nonsense around gem setup/teardown has disappeared, yay! Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20drm/i915: Ditch dev_priv->ums.mm_suspendDaniel Vetter
Again just complicates gem init functions and makes a general mess out of everything. Good riddance! v2: In my enthusiasm to start removing dri1/ums crud I went overboard a bit and killed parts of hangcheck. Resurrect it. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-20Merge branch 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux into ↵Dave Airlie
drm-next Merge AMDKFD it seems clean enough. * 'amdkfd-v6' of git://people.freedesktop.org/~gabbayo/linux: (29 commits) amdkfd: Implement the Get Version IOCTL amdkfd: Implement the Get Process Aperture IOCTL amdkfd: Implement the Get Clock Counters IOCTL amdkfd: Implement the Set Memory Policy IOCTL amdkfd: Implement the create/destroy/update queue IOCTLs amdkfd: Add interrupt handling module amdkfd: Add device queue manager module amdkfd: Add process queue manager module amdkfd: Add packet manager module amdkfd: Add module parameter of scheduling policy amdkfd: Add kernel queue module amdkfd: Add mqd_manager module amdkfd: Add queue module amdkfd: Add binding/unbinding calls to amd_iommu driver amdkfd: Add basic modules to amdkfd amdkfd: Add topology module to amdkfd amdkfd: Add amdkfd skeleton driver amdkfd: Add IOCTL set definitions of amdkfd Update MAINTAINERS and CREDITS files with amdkfd info drm/radeon: Add radeon <--> amdkfd interface ...
2014-11-20drm/cirrus: allow 32bpp framebuffers for cirrus drmZach Reizner
This patch allows framebuffers for cirrus to be created with 32bpp pixel formats provided that they do not violate certain restrictions of the cirrus hardware. v2: Use pci resource length for vram size. Signed-off-by: Zach Reizner <zachr@google.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/udl: add support to export a handle to a FD on UDL.Haixia Shi
Only importing an FD to a handle is currently supported on UDL, but the exporting functionality is equally useful. Signed-off-by: Haixia Shi <hshi@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/udl: add cache flags definitions for udl_gem_objectHaixia Shi
By default set udl_gem_object as cacheable, but set WC flag when attaching dmabuf. In udl_gem_mmap() update cache attributes based on the flags, similar to exynos_drm_gem_mmap(). Signed-off-by: Haixia Shi <hshi@chromium.org> Reviewed-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/cirrus: fix leaky driver load error handlingZach Reizner
Before this patch, cirrus_device_init could have failed while cirrus_mm_init succeeded and the driver would have reported overall success on load. This patch causes cirrus_device_init to return on the first error encountered. Reviewed-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/atomic_helper: Make it clear that commit_planes gets the old stateDaniel Vetter
Oversight from my kerneldoc cleanup when doing the original atomic helper series - I've only applied this clarification to the modeset related helpers, and not the plane update code. Remedy this asap. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm: s/enum_blob_list/enum_list/ in drm_propertyDaniel Vetter
I guess for hysterical raisins this was meant to be the way to read blob properties. But that's done with the two-stage approach which uses separate blob kms object and the special-purpose get_blob ioctl. Shipping userspace seems to have never relied on this, and the kernel also never put any blob thing onto that property. And nowadays it would blow up, e.g. in drm_property_destroy. Also it makes no sense to return values in an ioctl that only returns metadata about everything. So let's ditch all the internal code for the blob list, rename the list to be unambiguous and sprinkle comments all over the place to explain this peculiar piece of api. v2: Squash in fixup from Rob to remove now unused variables. Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/crtc: Polish kerneldocDaniel Vetter
- Make it clear that it's a negative errno (more in line with everything else). - Clean up the confusion around get_properties vs. getproperty ioctls: One reads per-obj property values, the other reads property metadata. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/atomic: Don't overrun the connector array when hotpluggingDaniel Vetter
Yet another fallout from not considering DP MST hotplug. With the previous patches we have stable indices, but it might still happen that a connector gets added between when we allocate the array and when we actually add a connector. Especially when we back off due to ww mutex contention or similar issues. So store the sizes of the arrays in struct drm_atomic_state and double check them. We don't really care about races except that we want to use a consistent value, so ACCESS_ONCE is all we need. And if we indeed notice that we'd overrun the array then just give up and restart the entire ioctl. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/atomic: Only destroy connector states with connection mutex heldDaniel Vetter
Otherwise the connector might have been unplugged and destroyed while we didn't look. Yet another fallout from DP MST hotplugging that I didn't consider. To make sure we get this right add an appropriate WARN_ON to drm_atomic_state_clear (obviously only when we actually have a state to clear up). And reorder all the state_clear and backoff calls to make it work out properly. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/atomic: Ensure that drm_connector_index is stableDaniel Vetter
I've totally forgotten that with DP MST connectors can now be hotplugged. And failed to adapt Rob's drm_atomic_state code (which predates connector hotplugging) to the new realities. The first step is to make sure that the connector indices used to access the arrays of pointers are stable. The connection mutex gives us enough guarantees for that, which means we won't unecessarily block on concurrent modesets or background probing. So add a locking WARN_ON and shuffle the code slightly to make sure we always hold the right lock. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/irq: BUG_ON() -> WARN_ON()Rob Clark
Let's make things a bit easier to debug when things go bad (potentially under console_lock). Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm/ttm: Avoid memory allocation from shrinker functions.Tetsuo Handa
Andrew Morton wrote: > On Wed, 12 Nov 2014 13:08:55 +0900 Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > Andrew Morton wrote: > > > Poor ttm guys - this is a bit of a trap we set for them. > > > > Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") > > changed to use sc->gfp_mask rather than GFP_KERNEL. > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), > > - GFP_KERNEL); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > > > But this bug is caused by sc->gfp_mask containing some flags which are not > > in GFP_KERNEL, right? Then, I think > > > > - pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp); > > + pages_to_free = kmalloc(npages_to_free * sizeof(struct page *), gfp & GFP_KERNEL); > > > > would hide this bug. > > > > But I think we should use GFP_ATOMIC (or drop __GFP_WAIT flag) > > Well no - ttm_page_pool_free() should stop calling kmalloc altogether. > Just do > > struct page *pages_to_free[16]; > > and rework the code to free 16 pages at a time. Easy. Well, ttm code wants to process 512 pages at a time for performance. Memory footprint increased by 512 * sizeof(struct page *) buffer is only 4096 bytes. What about using static buffer like below? ---------- >From d3cb5393c9c8099d6b37e769f78c31af1541fe8c Mon Sep 17 00:00:00 2001 From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Date: Thu, 13 Nov 2014 22:21:54 +0900 Subject: [PATCH] drm/ttm: Avoid memory allocation from shrinker functions. Commit a91576d7916f6cce ("drm/ttm: Pass GFP flags in order to avoid deadlock.") caused BUG_ON() due to sc->gfp_mask containing flags which are not in GFP_KERNEL. https://bugzilla.kernel.org/show_bug.cgi?id=87891 Changing from sc->gfp_mask to (sc->gfp_mask & GFP_KERNEL) would avoid the BUG_ON(), but avoiding memory allocation from shrinker function is better and reliable fix. Shrinker function is already serialized by global lock, and clean up function is called after shrinker function is unregistered. Thus, we can use static buffer when called from shrinker function and clean up function. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: stable <stable@kernel.org> [2.6.35+] Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm: remove unnecessary sizeof(u8)Fabian Frederick
sizeof(u8) is always 1. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20drm: omapdrm: remove unused variableBoris BREZILLON
Commit f9b9faf6d94dd29eab8c128905c7d091f955481d "drm: flip-work: change drm_flip_work_init prototype" changed the drm_flip_work_init prototype to a void function, which makes 'ret' an unused variable. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: add page_flipGerd Hoffmann
Implement crtc page_flip callback for bochsdrm. The qemu stdvga has no vblank signaling, so we have to fake it. We do so by instantly calling drm_send_vblank_event. Tested with kmscon. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: fix bochsdrmfb mmapGerd Hoffmann
Remove the mapping offset from the bo backing the fbdev framebuffer. Wire up fbdev mmap function to map the backing bo using ttm_fbdev_mmap. With that patch in place mmap(/dev/fb0) works as expected. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: add endian switching supportGerd Hoffmann
Recently (qemu 2.2+) the qemu stdvga got a register to switch the vga framebuffer endianness. This patch adds code to explicitly set the endianness of the framebuffer. In most cases this has no effect as the default is guest architecture endianness. It is needed though in case a architecture supports both big and little endian, i.e. for ppc64le. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-20bochs: little cleanupGerd Hoffmann
Drop some leftover, commented code. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2014-11-19drm/i915: No-Op enter/leave vt gem ioctlDaniel Vetter
We've killed ums support by now, it's time to reap the benefits. This one here is getting in the way of doing some ring init cleanup. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19drm/i915: Drop checks for initializationDaniel Vetter
KMS always intializes, this was only a valid check when userspace was still in control of the kernel driver. v2: Comment that we outright reject all dri1/ums params. Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Replace dri1 functions with drm_noopDaniel Vetter
Whether we'll reject them or no-op doesn't really matter ... Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: Remove DRI1 ring accessors and APIChris Wilson
With the deprecation of UMS, and by association DRI1, we have a tough choice when updating the ring access routines. We either rewrite the DRI1 routines blindly without testing (so likely to be broken) or take the liberty of declaring them no longer supported and remove them entirely. This takes the latter approach. v2: Also remove the DRI1 sarea updates Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fix rebase conflicts.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Pin the ringbuffer backing object to GGTT on-demandThomas Daniel
Same as with the context, pinning to GGTT regardless is harmful (it badly fragments the GGTT and can even exhaust it). Unfortunately, this case is also more complex than the previous one because we need to map and access the ringbuffer in several places along the execbuffer path (and we cannot make do by leaving the default ringbuffer pinned, as before). Also, the context object itself contains a pointer to the ringbuffer address that we have to keep updated if we are going to allow the ringbuffer to move around. v2: Same as with the context pinning, we cannot really do it during an interrupt. Also, pin the default ringbuffers objects regardless (makes error capture a lot easier). v3: Rebased. Take a pin reference of the ringbuffer for each item in the execlist request queue because the hardware may still be using the ringbuffer after the MI_USER_INTERRUPT to notify the seqno update is executed. The ringbuffer must remain pinned until the context save is complete. No longer pin and unpin ringbuffer in populate_lr_context() - this transient address is meaningless and the pinning can cause a sleep while atomic. v4: Moved ringbuffer pin and unpin into the lr_context_pin functions. Downgraded pinning check BUG_ONs to WARN_ONs. v5: Reinstated WARN_ONs for unexpected execlist states. Removed unused variable. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Pin the context backing objects to GGTT on-demandOscar Mateo
Up until now, we have pinned every logical ring context backing object during creation, and left it pinned until destruction. This made my life easier, but it's a harmful thing to do, because we cause fragmentation of the GGTT (and, eventually, we would run out of space). This patch makes the pinning on-demand: the backing objects of the two contexts that are written to the ELSP are pinned right before submission and unpinned once the hardware is done with them. The only context that is still pinned regardless is the global default one, so that the HWS can still be accessed in the same way (ring->status_page). v2: In the early version of this patch, we were pinning the context as we put it into the ELSP: on the one hand, this is very efficient because only a maximum two contexts are pinned at any given time, but on the other hand, we cannot really pin in interrupt time :( v3: Use a mutex rather than atomic_t to protect pin count to avoid races. Do not unpin default context in free_request. v4: Break out pin and unpin into functions. Fix style problems reported by checkpatch v5: Remove unpin_lock as all pinning and unpinning is done with the struct mutex already locked. Add WARN_ONs to make sure this is the case in future. Issue: VIZ-4277 Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Reviewed-by: Deepak S<deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915/bdw: Clean up execlist queue items in retire_workThomas Daniel
No longer create a work item to clean each execlist queue item. Instead, move retired execlist requests to a queue and clean up the items during retire_requests. v2: Fix legacy ring path broken during overzealous cleanup v3: Update idle detection to take execlists queue into account v4: Grab execlist lock when checking queue state v5: Fix leaking requests by freeing in execlists_retire_requests. Issue: VIZ-4274 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Akash Goel <akash.goels@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19assorted conversions to %p[dD]Al Viro
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2014-11-19Merge tag 'drm-intel-fixes-2014-11-19' into drm-intel-next-queuedDaniel Vetter
So with all the code movement and extraction in intel_pm.c in -next git is hopelessly confused with commit 2208d655a91f9879bd9a39ff9df05dd668b3512c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 14 09:25:29 2014 +0100 drm/i915: drop WaSetupGtModeTdRowDispatch:snb from -fixes. Worse even small changes in -next move around the conflict context so rerere is equally useless. Let's just backmerge and be done with it. Conflicts: drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_pm.c Except for git getting lost no tricky conflicts really. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-11-19drm/i915: disable rps irqs earlier during suspend/unloadImre Deak
After the previous patch RPS disabling doesn't depend any more on the first level interrupts being disabled, so we can move it everywhere earlier. Doing so let's us think about the uninitialization steps afterwards independently of any asynchronous RPS events that can happen atm. It also makes the system/runtime suspend time RPS disabling more uniform. Finally this gets rid of the WARN in intel_suspend_gt_powersave(), which we can hit if a final RPS work runs after we disabled the first level interrupts. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: sanitize rps irq disablingImre Deak
When disabling the RPS interrupts there is a tricky dependency between the thread disabling the interrupts, the RPS interrupt handler and the corresponding RPS work. The RPS work can reenable the interrupts, so there is no straightforward order in the disabling thread to (1) make sure that any RPS work is flushed and to (2) disable all RPS interrupts. Currently this is solved by masking the interrupts using two separate mask registers (first level display IMR and PM IMR) and doing the disabling when all first level interrupts are disabled. This works, but the requirement to run with all first level interrupts disabled is unnecessary making the suspend / unload time ordering of RPS disabling wrt. other unitialization steps difficult and error prone. Removing this restriction allows us to disable RPS early during suspend / unload and forget about it for the rest of the sequence. By adding a more explicit method for avoiding the above race, it also becomes easier to prove its correctness. Finally currently we can hit the WARN in snb_update_pm_irq(), when a final RPS work runs with the first level interrupts already disabled. This won't lead to any problem (due to the separate interrupt masks), but with the change in this and the next patch we can get rid of the WARN, while leaving it in place for other scenarios. To address the above points, add a new RPS interrupts_enabled flag and use this during RPS disabling to avoid requeuing the RPS work and reenabling of the RPS interrupts. Since the interrupt disabling happens now in intel_suspend_gt_powersave(), we will disable RPS interrupts explicitly during suspend (and not just through the first level mask), but there is no problem doing so, it's also more consistent and allows us to unify more of the RPS disabling during suspend and unload time in the next patch. v2/v3: - rebase on patch "drm/i915: move rps irq disable one level up" in the patchset Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: sanitize rps irq enablingImre Deak
Atm we first enable the RPS interrupts then we clear any pending ones. By this we could lose an interrupt arriving after we unmasked it. This may not be a problem as the caller should handle such a race, but logic still calls for the opposite order. Also we can delay enabling the interrupts until after all the RPS initialization is ready with the following order: 1. disable left-over RPS (earlier via intel_uncore_sanitize) 2. clear any pending RPS interrupts 3. initialize RPS 4. enable RPS interrupts This also allows us to do the 2. and 4. step the same way for all platforms, so let's follow this order to simplifying things. Also make sure any queued interrupts are also cleared. v2: - rebase on the GEN9 patches where we don't support RPS yet, so we musn't enable RPS interrupts on it (Paulo) v3: - avoid enabling RPS interrupts on GEN>9 too (Paulo) - clarify the RPS init sequence in the log message (Chris) - add POSTING_READ to gen6_reset_rps_interrupts() (Paulo) - WARN if any PM_IIR bits are set in gen6_enable_rps_interrupts() (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-19drm/i915: move rps irq disable one level upImre Deak
We disable the RPS interrupts for all platforms at the same spot, so move it one level up in the callstack to simplify things. No functional change. v2: - rebase on the GEN9 patches where RPS isn't supported yet, so we don't need to disable RPS interrupts on it (Paulo) v3: - avoid disabling the interrupts on GEN>9 too (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.46.0) at 2025-07-23 12:39:07 +0000