summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2014-12-17drm: get rid of direct property value accessRob Clark
For atomic drivers, we won't use the values array but instead shunt things off to obj->atomic_get_property(). So to simplify things make all read/write of properties values go through the accessors. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm: store property instead of id in obj attachmentRob Clark
Keep property pointer, instead of id, in per mode-object attachments. This will simplify things in later patches. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm: allow property validation for refcnted propsRob Clark
We can already have object properties, which technically can be fb's. Switch the property validation logic over to a get/put style interface so it can take a ref to refcnt'd objects, and then drop that ref after the driver has a chance to take it's own ref. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/atomic: Introduce state->obj backpointersDaniel Vetter
Useful since this way we can pass around just the state objects and will get ther real object, too. Specifically this allows us to again simplify the parameters for set_crtc_for_plane. v2: msm already has it's own specific plane_reset hook, don't forget that one! v3: Fixup kerneldoc, reported by 0-day builder. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> (v2) Tested-by: Rob Clark <robdclark@gmail.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-17drm/atomic-helper: Again check modeset *before* plane statesDaniel Vetter
This essentially reverts commit 934ce1c23624526d9d784e0499190bb48113e6f4 Author: Rob Clark <robdclark@gmail.com> Date: Wed Nov 19 16:41:33 2014 -0500 drm/atomic: check mode_changed *after* atomic_check Depending upon the driver both orders (or maybe even interleaving) is required: - If ->atomic_check updates ->mode_changed then helper_check_modeset must be run afters. - If ->atomic_check depends upon accurate adjusted dotclock values for e.g. watermarks, then helper_check_modeset must be run first. The failure mode in the first case is usually a totally angry hw because the pixel format switching doesn't happen. The failure mode in the later case is usually nothing, since in most cases the old adjusted mode from the previous modeset wont be too far off to be a problem. So just underruns and perhaps even just suboptimal (from a power consumption) watermarks. Furthermore in the transitional helpers we only call ->atomic_check after the new modeset state has been fully set up (and hence computed). Given that asymmetry in expected failure modes I think it's safer to go back to the older order. So do that and give msm a special check function to compensate. Also update kerneldoc to explain this a bit. v2: Actually add the missing hunk Rob spotted. v3: Move msm_atomic_check into msm_atomic.c, requested by Rob. Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Tested-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-17drm/atomic-helper: Export both plane and modeset check helpersDaniel Vetter
The default call sequence for these two parts won't fit for all drivers. So export the two pieces and explain with a bit of kerneldoc when each should be called. v2: Squash in fixup from Rob to actually add the newly exported functions to headers Cc: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2014-12-17drm/atomic: fix potential null ptr on plane enableRob Clark
When a plane is being enabled, plane->crtc has not been set yet. Use plane->state->crtc. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm: Do basic sanity checks for user modesVille Syrjälä
Currently userspace is allowed to pass in basiclly any kind of garbage to setcrtc. Try to catch the cases where the timings make no sense by passing the mode through drm_mode_validate_basic(). One concern here is that we now start to block some modes that have worked in the past. It's at least possible with when using i915 with LVDS/eDP. Previously we've just ignored everything but hdisplay/vdisplay from the user mode and just overwritten the rest with the panel fixed mode. So if someone has been passing a mode with just those populated that would now stop working. If that is a real problem, we can't add these checks to the core code and each driver would have to have its own sanity checks. So fingers crossed... Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm: Perform basic sanity checks on probed modesVille Syrjälä
Make sure the timings of probed modes at least pass some very basic sanity checks. The checks include: - clock,hdisplay,vdisplay are non zero - sync pulse fits within the blanking period - htotal,vtotal are big enough I have not checked all the drivers to see if the modes the generate might violate these constraints. I'm hoping not, because that would mean either abandoning the idea of doing this from the core code, or fixing the drivers. I'm not entirely sure about limiting the sync pulse to the blanking period. Intel hardware doesn't support such things, but some other hardware might. However at least HDMI doesn't allow having sync pulse edges within the active period, so I'm thinking the check is probably OK to have in the common code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm: Reorganize probed mode validationVille Syrjälä
Make drm_mode_validate_size() and drm_mode_validate_flag() deal with a single mode instead of having each iterate through the mode list. The hope is that in the future we might be able to share various mode validation functions between modeset and get_modes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/i915: Organize bind_vma funcsRodrigo Vivi
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/i915: Organize INSTDONE report for future.Rodrigo Vivi
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/i915: Organize PDP regs report for future.Rodrigo Vivi
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/i915: Organize PPGTT initRodrigo Vivi
Let's be optimistic that for future platforms memory management doesn't change that much and reuse gen8 function for PPGTT init. Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/i915: Organize Fence registers for future enablement.Rodrigo Vivi
Let's be optimistic that for future platforms this will remain the same and reorg a bit. This reorg in if blocks instead of switch make life easier for future platform support addition. v2: Jani pointed out I was missing reg_830 for some gen3 platforms. So let's make this platforms subcases of Gen checks. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-17drm/msm: Deletion of unnecessary checks before the function call ↵Markus Elfring
"release_firmware" The release_firmware() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-12-17drm/msm: Deletion of unnecessary checks before two function callsMarkus Elfring
The functions framebuffer_release() and vunmap() perform also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
2014-12-17drm/tegra: dc: Select root window for event dispatchSean Paul
In finish pageflip, the driver was not selecting the root window when dispatching events. This exposed a race where a plane update would change the window selection and cause tegra_dc_finish_page_flip to check the wrong base address. This patch also protects access to the window selection register as well as the registers affected by it. Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/tegra: gem: Use the proper size for GEM objectsThierry Reding
If the requested buffer size wasn't a multiple of the page size, the IOMMU code would round down the size to the next multiple of the page size, thereby causing translation errors. To fix this we no longer pass around the requested size but reuse the computed size of the GEM object. This is already rounded to the next page boundary, so mapping that size works out fine. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/tegra: gem: Flush buffer objects upon allocationThierry Reding
Buffers obtained via shmem may still have associated cachelines. If they aren't properly flushed they may cause framebuffer corruption if the cache gets flushed after the application has drawn to it. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/tegra: dc: Fix a potential race on page-flip completionThierry Reding
Page-flip completion could race with page-flip submission, so extend the critical section to include all accesses to page-flip related data. Reported-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/tegra: dc: Consistently use the same pipeThierry Reding
The hardware pipe numbers don't always match the DRM CRTC indices. This can happen for example if the first display controller defers probe, causing it to be registered with DRM after the second display controller. When that happens the hardware pipe numbers and DRM CRTC indices become different. Make sure that the CRTC index is always used when accessing per-CRTC VBLANK data. This can be ensured by using the drm_crtc_vblank_*() API, which will do the right thing automatically given a struct drm_crtc *. Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/irq: Add drm_crtc_vblank_count()Thierry Reding
This function is the KMS native variant of drm_vblank_count(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/irq: Add drm_crtc_handle_vblank()Thierry Reding
This function is the KMS native variant of drm_handle_vblank(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/irq: Add drm_crtc_send_vblank_event()Thierry Reding
This function is the KMS native variant of drm_send_vblank_event(). It takes a struct drm_crtc * instead of a struct drm_device * and an index of the CRTC. Eventually the goal is to access vblank data through the CRTC only so that the per-CRTC data can be moved to struct drm_crtc. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com>
2014-12-17drm/radeon: Assign VMID to PASID for IH in non-HWS modeBen Goz
This patch fixes a bug in kgd_set_pasid_vmid_mapping(), where the function only updated the ATC registers (IOMMU) with the new VMID <--> PASID mapping, but didn't update the IH (Interrupt) registers. The bug only occurs when using non-HWS mode. In HWS mode, the CP automatically does the VMID <--> PASID mapping. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com>
2015-01-04drm/radeon: do not leave queue acquired if timeout happens in kgd_hqd_destroy()Alexey Khoroshilov
If timeout happens, kgd_hqd_destroy() just returns -ETIME leaving queue acquired. It may cause a deadlock, so the patch proposes to release queue before return. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
2015-01-04drm/amdkfd: Load mqd to hqd in non-HWS modeBen Goz
This patch fixes a bug in DQM, where the MQD of a newly created compute queue is not loaded to an HQD slot. As a result, the CP never reads packets from this queue. This bug happens only in non-HWS (hardware scheduling) mode. In HWS mode, the CP is responsible of loading MQDs to HQDs slots. Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com>
2014-12-16drm/info: Remove unused codeThierry Reding
Commit 28a62277e06f ("drm: Convert proc files to seq_file and introduce debugfs") converted /proc files to debugfs and in the process dropped the entry for the vblank statistics. Since that file has been gone for almost five years, there is no use to keep the code that provides the file's content around. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Disable PSMI sleep messages on all rings around context switchesChris Wilson
There exists a current workaround to prevent a hang on context switch should the ring go to sleep in the middle of the restore, WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In spite of disabling arbitration (which prevents the ring from powering down during the critical section) we were still hitting hangs that had the hallmarks of the known erratum. That is we are still seeing hangs "on the last instruction in the context restore". By comparing -nightly (broken) with requests (working), we were able to deduce that it was the semaphore LRI cross-talk that reproduced the original failure. The key was that requests implemented deferred semaphore signalling, and disabling that, i.e. emitting the semaphore signal to every other ring after every batch restored the frequent hang. Explicitly disabling PSMI sleep on the RCS ring was insufficient, all the rings had to be awake to prevent the hangs. Fortunately, we can reduce the wakelock to the MI_SET_CONTEXT operation itself, and so should be able to limit the extra power implications. Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above products, we should apply this extra hammer for all of the same platforms despite so far that we have only been able to reproduce the hang on certain ivb and hsw models. The last question is whether we want to always use the extra hammer or only when we know semaphores are in operation. At the moment, we only use LRI on non-RCS rings for semaphores, but that may change in the future with the possibility of reintroducing this bug under subtle conditions. v2: Make it explicit that the PSMI LRI are an extension to the original workaround for the other rings. v3: Bikeshedding variable names and whitespacing Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Peter Frühberger <fritsch@xbmc.org> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16drm/i915: Force the CS stall for invalidate flushesChris Wilson
In order to act as a full command barrier by itself, we need to tell the pipecontrol to actually stall the command streamer while the flush runs. We require the full command barrier before operations like MI_SET_CONTEXT, which currently rely on a prior invalidate flush. References: https://bugs.freedesktop.org/show_bug.cgi?id=83677 Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16drm/i915: Invalidate media caches on gen7Chris Wilson
In the gen7 pipe control there is an extra bit to flush the media caches, so let's set it during cache invalidation flushes. v2: Rename to MEDIA_STATE_CLEAR to be more inline with spec. Cc: Simon Farnsworth <simon@farnz.org.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16drm/i915: tame the chattermouth (v2)Rob Clark
Many distro's have mechanism in place to collect and automatically file bugs for failed WARN()s. And since i915 has a lot of hw state sanity checks which result in WARN(), it generates quite a lot of noise which is somewhat disconcerting to the end user. Separate out the internal hw-is-in-the-state-I-expected checks into I915_STATE_WARN()s and allow configuration via i915.verbose_checks module param about whether this will generate a full blown stacktrace or just DRM_ERROR(). The new moduleparam defaults to true, so by default there is no change in behavior. And even when disabled, you will still get an error message logged. v2: paint the macro names blue, clarify that the default behavior remains the same as before Signed-off-by: Rob Clark <robdclark@gmail.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Warn about missing context state workarounds only onceMichel Thierry
Otherwise, new platforms without workarounds will hit this warning for every new context created. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Use true PPGTT in Gen8+ when execlists are enabledMichel Thierry
In Gen8+, full ppgtt needs execlist, otherwise the ctx switch can hang. Also remove the current restriction, a user should be able to explicitly set ppgtt=2. Note, this patch considers that execlist support has been enabled by default on Gen8. v2: Remove non-default restriction and clarify commit message (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Michel Thierry <michel.thierry@intel.com> [danvet: s/comment/commit message/ in the commit message since that's what Michel meant as per our irc discussion.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Skip gunit save/restore for cherryviewDeepak S
With cherryview onwards, Gunit hardware itself save and restore all the Gunit registers. Skipping the "vlv_save_gunit_s0ix_state" & "vlv_restore_gunit_s0ix_state" for cherryview in S3/S0ix sequence. Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915/chv: Use timeout mode for RC6 on chvDeepak S
Higher RC6 residency is observed using timeout mode instead of EI mode. It's Recommended to use TO Method for RC6. v2: Add comment about timeout threshold. (Tom) Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Add GPGPU_THREADS_DISPATCHED to the register whitelistJordan Justen
This will allow us to read the number of dispatched compute threads for GL_ARB_pipeline_statistics_query. Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Tidy up execbuffer command parsing codeBrad Volkin
Move it to a separate function since the main do_execbuffer function already has so much going on. v2: - Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7 feedback) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Mark shadow batch buffers as purgeableBrad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects as purgeable after they are on the active list. v2: - Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get fnc (danvet, from v4 6/7 feedback) v3: - Remove duplicate 'madv = I915_MADV_WILLNEED' (danvet, from v6 4/5) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Use batch length instead of object size in command parserBrad Volkin
Previously we couldn't trust the user-supplied batch length because it came directly from userspace (i.e. untrusted code). It would have affected what commands software parsed without regard to what hardware would actually execute, leaving a potential hole. With the parser now copying the user supplied batch buffer and writing MI_NOP commands to any space after the copied region, we can safely use the batch length input. This should be a performance win as the actual batch length is frequently much smaller than the allocated object size. v2: Fix handling of non-zero batch_start_offset Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Use batch pools with the command parserBrad Volkin
This patch sets up all of the tracking and copying necessary to use batch pools with the command parser and dispatches the copied (shadow) batch to the hardware. After this patch, the parser is in 'enabling' mode. Note that performance takes a hit from the copy in some cases and will likely need some work. At a rough pass, the memcpy appears to be the bottleneck. Without having done a deeper analysis, two ideas that come to mind are: 1) Copy sections of the batch at a time, as they are reached by parsing. Might improve cache locality. 2) Copy only up to the userspace-supplied batch length and memset the rest of the buffer. Reduces the number of reads. v2: - Remove setting the capacity of the pool - One global pool instead of per-ring pools - Replace batch_obj with shadow_batch_obj and hook into eb->vmas - Memset any space in the shadow batch beyond what gets copied - Rebased on execlist prep refactoring v3: - Rebase on chained batch handling - Squash in setting the secure dispatch flag - Add a note about the interaction w/secure dispatch pinning - Check for request->batch_obj == NULL in i915_gem_free_request v4: - Fix read domains for shadow_batch_obj - Remove the set_to_gtt_domain call from i915_parse_cmds - ggtt_pin/unpin in the parser block to simplify error handling - Check USES_FULL_PPGTT before setting DISPATCH_SECURE flag - Remove i915_gem_batch_pool_put calls v5: - Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after the parser (danvet, from v4 0/7 feedback) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: Implement a framework for batch buffer poolsBrad Volkin
This adds a small module for managing a pool of batch buffers. The only current use case is for the command parser, as described in the kerneldoc in the patch. The code is simple, but separating it out makes it easier to change the underlying algorithms and to extend to future use cases should they arise. The interface is simple: init to create an empty pool, fini to clean it up, get to obtain a new buffer. Note that all buffers are expected to be inactive before cleaning up the pool. Locking is currently based on the caller holding the struct_mutex. We already do that in the places where we will use the batch pool for the command parser. v2: - s/BUG_ON/WARN_ON/ for locking assertions - Remove the cap on pool size - Switch from alloc/free to init/fini v3: - Idiomatic looping structure in _fini - Correct handling of purged objects - Don't return a buffer that's too much larger than needed v4: - Rebased to latest -nightly v5: - Remove _put() function and clean up comments to match v6: - Move purged check inside the loop (danvet, from v4 1/7 feedback) v7: - Use single list instead of two. (Chris W) - s/active_list/cache_list - Squashed in debug patches (Chris W) drm/i915: Add a batch pool debugfs file It provides some useful information about the buffers in the global command parser batch pool. v2: rebase on global pool instead of per-ring pools v3: rebase drm/i915: Add batch pool details to i915_gem_objects debugfs To better account for the potentially large memory consumption of the batch pool. v8: - Keep cache in LRU order (danvet, from v6 1/5 feedback) Issue: VIZ-4719 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-By: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/i915: fix use after free during eDP encoder destroyingImre Deak
After commit a18c0af171bfb875012da26f23df051004726973 uthor: Thierry Reding <treding@nvidia.com> Date: Wed Dec 10 11:38:49 2014 +0100 drm: Zero out DRM object memory upon cleanup we will use the eDP encoder during destroying it. Fix this by calling drm_encoder_cleanup() at a point when the encoder is not used any more. This caused a NULL pointer dereference in pps_lock(), I can't see that it caused any other problem. All the other encoders seem to call drm_encoder_cleanup() at a safe place. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-16drm/cache: Use wbinvd helpersBen Widawsky
When the original drm code was written there were no centralized functions for doing a coordinated wbinvd across all CPUs. Now (since 2010) there are, so use them instead of rolling a new one. v2: On x86 UP systems the wbinvd_on_all_cpus() is defined as a static inline in smp.h. We must therefore include this file so we don't get compiler errors. This error was found by 0-DAY kernel test infrastructure. We only need this for x86. Cc: Intel GFX <intel-gfx@lists.freedesktop.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-15Merge tag 'staging-3.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging driver updates from Greg KH: "Here's the big staging tree pull request for 3.19-rc1. We continued to delete more lines than were added, always a good thing, but not at a huge rate this release, only about 70k lines removed overall mostly from removing the horrid bcm driver. Lots of normal staging driver cleanups and fixes all over the place, well over a thousand of them, the shortlog shows all the horrid details. The "contentious" thing here is the movement of the Android binder code out of staging into the "real" part of the kernel. This is code that has been stable for a few years now and is working as-is in the tens of millions of devices with no issues. Yes, the code is horrid, and the userspace api leaves a lot to be desired, but it's not going to change due to legacy issues that we have no control over. Because so many devices and companies rely on this, and the code is stable, might as well promote it out of staging. This was all discussed at the Linux Plumbers conference, and everyone participating agreed that this was the best way forward. There is work happening to replace the binder code with something new that is happening right now, but I don't expect to see the results of that work for another year at the earliest. If that ever happens, and Android switches over to it, I'll gladly remove this version. As for maintainers, I'll be glad to maintain this code, I've been doing it for the past few years with no problems. I'll send a MAINTAINERS entry for it before 3.19-final is out, still need to talk to the Google developers about if they are willing to help with it or not, last I checked they were, which was good. All of these patches have been in linux-next for a while with no reported issues" * tag 'staging-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1382 commits) Staging: slicoss: Fix long line issues in slicoss.c staging: rtl8712: remove unnecessary else after return staging: comedi: change some printk calls to pr_err staging: rtl8723au: hal: Removed the extra semicolon lustre: Deletion of unnecessary checks before three function calls staging: lustre: fix sparse warnings: static function declaration staging: lustre: fixed sparse warnings related to static declarations staging: unisys: remove duplicate header staging: unisys: remove unneeded structure staging: ft1000 : replace __attribute ((__packed__) with __packed drivers: staging: rtl8192e: Include "asm/unaligned.h" instead of "access_ok.h" in "rtl819x_BAProc.c" Drivers:staging:rtl8192e: Fixed checkpatch warning Drivers:staging:clocking-wizard: Added a newline staging: clocking-wizard: check for a valid clk_name pointer staging: rtl8723au: Hal_InitPGData() avoid unnecessary typecasts staging: rtl8723au: _DisableAnalog(): Avoid zero-init variables unnecessarily staging: rtl8723au: Remove unnecessary wrapper _ResetDigitalProcedure1() staging: rtl8723au: _ResetDigitalProcedure1_92C() reduce code obfuscation staging: rtl8723au: Remove unnecessary wrapper _DisableRFAFEAndResetBB() staging: rtl8723au: _DisableRFAFEAndResetBB8192C(): Reduce code obfuscation ...
2014-12-15Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds
Pull drm updates from Dave Airlie: "Highlights: - AMD KFD driver merge This is the AMD HSA interface for exposing a lowlevel interface for GPGPU use. They have an open source userspace built on top of this interface, and the code looks as good as it was going to get out of tree. - Initial atomic modesetting work The need for an atomic modesetting interface to allow userspace to try and send a complete set of modesetting state to the driver has arisen, and been suffering from neglect this past year. No more, the start of the common code and changes for msm driver to use it are in this tree. Ongoing work to get the userspace ioctl finished and the code clean will probably wait until next kernel. - DisplayID 1.3 and tiled monitor exposed to userspace. Tiled monitor property is now exposed for userspace to make use of. - Rockchip drm driver merged. - imx gpu driver moved out of staging Other stuff: - core: panel - MIPI DSI + new panels. expose suggested x/y properties for virtual GPUs - i915: Initial Skylake (SKL) support gen3/4 reset work start of dri1/ums removal infoframe tracking fixes for lots of things. - nouveau: tegra k1 voltage support GM204 modesetting support GT21x memory reclocking work - radeon: CI dpm fixes GPUVM improvements Initial DPM fan control - rcar-du: HDMI support added removed some support for old boards slave encoder driver for Analog Devices adv7511 - exynos: Exynos4415 SoC support - msm: a4xx gpu support atomic helper conversion - tegra: iommu support universal plane support ganged-mode DSI support - sti: HDMI i2c improvements - vmwgfx: some late fixes. - qxl: use suggested x/y properties" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (969 commits) drm: sti: fix module compilation issue drm/i915: save/restore GMBUS freq across suspend/resume on gen4 drm: sti: correctly cleanup CRTC and planes drm: sti: add HQVDP plane drm: sti: add cursor plane drm: sti: enable auxiliary CRTC drm: sti: fix delay in VTG programming drm: sti: prepare sti_tvout to support auxiliary crtc drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off} drm: sti: fix hdmi avi infoframe drm: sti: remove event lock while disabling vblank drm: sti: simplify gdp code drm: sti: clear all mixer control drm: sti: remove gpio for HDMI hot plug detection drm: sti: allow to change hdmi ddc i2c adapter drm/doc: Document drm_add_modes_noedid() usage drm/i915: Remove '& 0xffff' from the mask given to WA_REG() drm/i915: Invert the mask and val arguments in wa_add() and WA_REG() drm: Zero out DRM object memory upon cleanup drm/i915/bdw: Fix the write setting up the WIZ hashing mode ...
2014-12-15drm/i915: sanitize RPS resetting during GPU resetImre Deak
Atm, we don't disable RPS interrupts and related work items before resetting the GPU. This may interfere with the following GPU initialization and cause RPS interrupts to show up in PM_IIR too early before calling gen6_enable_rps_interrupts() (triggering a WARN there). Solve this by disabling RPS interrupts and flushing any related work items before resetting the GPU. v2: - split out the common parts of the gt suspend and the new gt reset functions (Paulo) v3: - remove the check for UMS, it's a NOP nowadays (Daniel) Reported-by: He, Shuang <shuang.he@intel.com> Testcase: igt/gem_reset_stats/ban-render Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-15drm/i915: move RPS PM_IER enabling to gen6_enable_rps_interruptsImre Deak
Paulo noticed that we don't enable RPS interrupts via PM_IER in gen6_enable_rps_interrupts(). This wasn't a problem so far, since the only place we disabled RPS interrupts was during system/runtime suspend and after that we reenable all interrupts in the IRQ pre/postinstall hooks. In the next patch we'll disable/reenable RPS interrupts during GPU reset too, but not call IRQ uninstall, pre/postinstall hooks, so there the above wouldn't work. The logical place for programming PM_IER is gen6_enable_rps_interrupts() and this also makes the function more symmetric with gen6_disable_rps_interrupts(), so move the programming there from the postinstall hooks. Note that these changes don't affect the ILK RPS interrupt code, which could be sanitized in a similar way. But that can be done as a follow-up. Credits-to: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-15drm/i915/skl: Skylake also supports DP MSTDamien Lespiau
I've checked that TRANS_DDI_MODE, DP_TP_CTL MST bits are identical to HSW/BDW on SKL, as well as the long vs short HPD bits. So we have a good chance to be working as well as prevous platforms. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>