- 20 May, 2014 19 commits
-
-
Ville Syrjälä authored
Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Reviewed-by:
-
Daniel Vetter authored
Besides the fairly useless BUG_ON the logic is completely generic and cane be used on any platform what wants to reuse the shared dpll support code. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
This is the last piece of code which write state to the hardware in the ironalake ->crtc_mode_set callback. I think we could merge this with the pll->enable hook, but otoh the ordering requirements with the ldvs port are really tricky. Doing the FP0/1 writes up-front before we even prepare the lvds port (in the pre_pll_enable hook) like on i9xx seems safest. With this ilk+ platforms are now ready for runtime PM with DPMS. Since hsw/bdw also support runtime pm besides snb we need to first make the haswell code save before we can touch the core code. Reviewed-by:
-
Daniel Vetter authored
Instead of every time it isn't active: We only need to do that when the pll is currently unused, i.e. when pll->refcount == 0. For paranoia add a warning for the ibx case where plls have a fixed mapping and hence should always be unused after the call to intel_put_shared_dpll. v2: Simplify control flow and use struct assignment instead of memcpy as suggested by Damien. Reviewed-by:
-
Daniel Vetter authored
With this all hw writes are also gone from the ->crtc_mode_set hook on vlv. I wondered whether we should track more of the pll state in the pipe config, but otoh as long as we don't have shared plls that's not really useful - the cross-checking of the port clock should be sufficient. While at it also de-magic some of the pipe checks, this has been irking me since a long time. Whit this vlv is now ready for runtime PM on dpms. If we'd have runtime PM support in general ... Reviewed-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Daniel Vetter authored
These two writes are the very last hw writes from the ->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit different, so this here is just warm-up. Reviewed-by:
-
Daniel Vetter authored
Again the same story: This code just transform sw state from the pipe config into hardware state. And again we can't move the pll code, but this time around because the state isn't properly tracked in the pipe config. Reviewed-by:
-
Daniel Vetter authored
Again this code just transforms sw state from the pipe config into hardware state, so we can just move it around. Unfortunately again a few forward declarations since intel_display.c is becoming a bit of a mess. Note that both for i9xx and ironlake code the only things remaining in the ->crtc_mode_set hook is now the clock state computation and sharing code. That needs to be moved into the compute config stage so that we can catch impossible configurations earlier. Also note that some of the DPLL hw setup code is still run from within ->crtc_mode_set, namele the pll->mode_set callback. We need to move that first before we can do fancy things like enable runtime PM for dpms off. v2: Make it compile again after the rebase, bisectability issue reported by Wu Fengguang. Reviewed-by:
-
Daniel Vetter authored
Now this really should be in the pipe config somewhere, but till now it isn't. We can at least move it up a bit next to all the other pll code since intel_dp_set_m_n really doesn't depend upon this. This is just prep work so that moving all the hw frobbing code from ->crtc_mode_set to ->crtc_enable is clean. v2: Do the same for haswell while at it, not just for ivb. Reviewed-by:
-
Daniel Vetter authored
All these functions simply convert sw state as encoded in the pipe config or primary framebuffer into hardware state. So we can move them all into the crtc enable hook. Unfortunately this means a little bit of duplication between the i9xx and vlv functions, but since we already have highly refactored code I think this is acceptable. Also a pile of forward declarations unfortunately. Note also that the various <platform>_update_pll functions are still called from within the ->crtc_mode_set hook. Mostly they compute the clock state for the pipe config, but unfortunately there are some random register writes interspersed. Those need to be moved out first before we can enable runtime PM for DPMS. Reviewed-by:
-
Chris Wilson authored
Before the process killer is invoked, oom-notifiers are executed for one last try at recovering pages. We can hook into this callback to be sure that everything that can be is purged from our page lists, and to give a summary of how much memory is still pinned by the GPU in the case of an oom. This should be really valuable for debugging OOM issues. Note that the last-ditch effort call to shrink_all we've previously called from our normal shrinker when we could free as much as the vm demaned is moved into the oom notifier. Since the shrinker accounting races against bind/unbind operations we might have called shrink_all prematurely, which this approach with an oom notifier avoids. References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
lu hua <huax.lu@intel.com> [danvet: Bikeshed logical | into || and pimp commit message.] Signed-off-by:
-
Ville Syrjälä authored
We're using the reset domains bits for g4x on ilk. But on ilk those bits actually shifted by one bit. Fix it up so that we use the correct bits. We were actually always writing 0x2 to the reset domain bits, which is a reserved value. In practice it looks like the hardware ignores that value since nothing happens if I write that value when there's a 3D workload running. Writing the _correct_ render domain value actually makes the GPU stop. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
We should be waiting for the reset bit to clear, not remain set. Signed-off-by:
-
Ville Syrjälä authored
There are comments in the gen4-5 reset functions stating that we can't reset render and media without also doing a display reset. But that's exactly what the code does, ie. we don't perform a display reset. Drop the bogus comments. Signed-off-by:
-
Chris Wilson authored
Try to flush out dirty pages into the swapcache (and from there into the swapfile) when under memory pressure and forced to drop GEM objects from memory. In effect, this should just allow us to discard unused pages for memory reclaim and to start writeback earlier. v2: Hugh Dickins warned that explicitly starting writeback from shrink_slab was prone to deadlocks within shmemfs. Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
Robert Beckett <robert.beckett@intel.com> Reviewed-by:
Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by:
-
Chris Wilson authored
We can share a few lines of tricky lock handling we need to use for both shrinker routines and in the process fix the return value for count() when reporting a deadlock. Signed-off-by:
-
Chris Wilson authored
When the machine is under a lot of memory pressure and being stressed by multiple GPU threads, we quite often report fewer than shrinker->batch (i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to skip calling into i915.ko to release pages, despite the GPU holding onto most of the physical pages in its active lists. References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by:
-
Chris Wilson authored
shmemfs first checks if there is enough memory to allocate the page and reports ENOSPC should there be insufficient, along with the usual ENOMEM for a genuine allocation failure. We use ENOSPC in our driver to mean that we have run out of aperture space and so want to translate the error from shmemfs back to our usual understanding of ENOMEM. None of the the other GEM users appear to distinguish between ENOMEM and ENOSPC in their error handling, hence it is easiest to do the fixup in i915.ko Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
-
- 19 May, 2014 11 commits
-
-
Shashank Sharma authored
This patch adds a mmio base address variable for DSI display, to make the DSI code generic, so that, if required, the same code can be re-used for future platforms with different mmio base. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
Daniel Vetter authored
We can apperently miss them, but breaking the entire driver hampers testing. So bail out after one minute, our customerary "this is a lost cause" timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=78383Reviewed-by:
-
Imre Deak authored
So far we used the wrong opcodes to access the DSI registers, so the register writes during DSI programming didn't actually succeed and left the registers unchanged. This wasn't a problem for the initial modeset, where the BIOS-programmed values happened to work, but after resuming from s0ix these registers are reset and failing to program them results in a blank screen. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
These opcodes are not specific for an endpoint, but are the same for all endpoints. So rename them accordingly, using the name the VLV2 sideband HAS uses. Also move the macros to the .c file, since they aren't used anywhere else. Signed-off-by:
-
Robin Schroer authored
Fixed several switch statements, curly braces, dereference operators and keywords. Signed-off-by:
Robin Schroer <sulamiification@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Our two ->crtc_mode_set callbacks really don't care whether the fb is pinned and set up already or not - all the state computation and handling which originally looked at the framebuffer is already using the indirection through the pipe configuration. Eventually we want to move this up a bit more, but as long as the crtc mode_set callback still exists (and as long as we don't need to pin an entire pile of planes due to atomic modesets) there's not much point in it. So I'll let this be for now. v2: Don't forget about haswell ... Reviewed-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Daniel Vetter authored
A lot of the code in set_base is uncessary when the crtc is off, so we can get rid of it all. Also, we don't need to call the fbc/psr update functions since the crtc enable/disable hooks do that already. The only things we really need are: - Pin the new framebuffer and potentially unpin the old framebuffer (if the crtc has been on and we only change the configuration). - Update the plane registers. The first step will move out of platform code with the very next patch. v2: Don't forget about haswell ... Reviewed-by:
-
Daniel Vetter authored
My plan here is to split up set_base into a prepare step, which does the pinning, and a commit stage, which updates the hw state. Eventually we should be able to move the prepare step at the beginning of any atomic update. For now I only want to move the commit step into the crtc_enable callbacks. As a prep step sprinkle intel_edp_psr_update all over the place so that we don't have to concern ourselves with that in the commit step. v2: Rebase on top of Ville's enable/disable functions for all planes. v3: Rebase more. Reviewed-by: Akash Goel <akash.goel@intel.com> (v2) Signed-off-by: -
Daniel Vetter authored
Just for consistency, this patch won't fix anything really. v2: Rebase over all the recent plane enabling shuffling. Reviewed-by: Akash Goel <akash.goel@intel.com> (v1) Signed-off-by: -
Daniel Vetter authored
Way back we've used this to reject framebuffers with unsupported pixel formats. But since the modesetting reorg with the compute config stage we reject those much earlier and just BUG() in this callback. So switch to a void return type. Reviewed-by:
-
Chris Wilson authored
More fallout from commit c8725f3d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Mar 17 12:21:55 2014 +0000 drm/i915: Do not call retire_requests from wait_for_rendering is that we can completely fill all of memory using small objects, such that we exhaust the filp space, and spend all of our time evicting objects from the aperture. As such, we never fill the ring, and never trigger the last resort flushing in commit 1cf0ba14 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon May 5 09:07:33 2014 +0100 drm/i915: Flush request queue when waiting for ring space and so all the requests are left active and the objects keep that last active reference. Eventually the system comes to a halt as it runs out of memory. The impact is mainly limited to test cases as regular userspace will trigger retirement by manually checking whether an object is active. Testcase: igt/gem_lut_handle Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78724Signed-off-by:
Guo Jinxian <jinxianx.guo@intel.com> Signed-off-by:
-
- 16 May, 2014 10 commits
-
-
Chris Wilson authored
Since commit 691e6415 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Apr 9 09:07:36 2014 +0100 drm/i915: Always use kref tracking for all contexts. we have contexts everywhere, and so we must be careful to distinguish fake contexts, which do not have an associated bo, and real ones, which do. In particular, we now need to be careful not to dereference NULL pointers. This is one such example, as the commit highlighted above failed to move the unpinning of the default ctx object into the real-context-only branch. Reported-by:
-
Ville Syrjälä authored
Some platforms have a shared error interrupt, so if FIFO underrun reporting gets disabled for one pipe/transcoder it gets disabled for all pipes/transcoders. When we disable FIFO underrun reporting we check whether the interrupt was enabled or not. If it wasn't we might have missed an underrun and we perform one last check right there. Currently we print a debug message when an underrun is detect using this mechanism. Promote the message to DRM_ERROR() to match the other underrun error messages. Signed-off-by:
-
Chris Wilson authored
By exporting the ability to map user address and inserting PTEs representing their backing pages into the GTT, we can exploit UMA in order to utilize normal application data as a texture source or even as a render target (depending upon the capabilities of the chipset). This has a number of uses, with zero-copy downloads to the GPU and efficient readback making the intermixed streaming of CPU and GPU operations fairly efficient. This ability has many widespread implications from faster rendering of client-side software rasterisers (chromium), mitigation of stalls due to read back (firefox) and to faster pipelining of texture data (such as pixel buffer objects in GL or data blobs in CL). v2: Compile with CONFIG_MMU_NOTIFIER v3: We can sleep while performing invalidate-range, which we can utilise to drop our page references prior to the kernel manipulating the vma (for either discard or cloning) and so protect normal users. v4: Only run the invalidate notifier if the range intercepts the bo. v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers v6: Recheck after reacquire mutex for lost mmu. v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary. v8: Fix rebasing error after forwarding porting the back port. v9: Limit the userptr to page aligned entries. We now expect userspace to handle all the offset-in-page adjustments itself. v10: Prevent vma from being copied across fork to avoid issues with cow. v11: Drop vma behaviour changes -- locking is nigh on impossible. Use a worker to load user pages to avoid lock inversions. v12: Use get_task_mm()/mmput() for correct refcounting of mm. v13: Use a worker to release the mmu_notifier to avoid lock inversion v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer with its own locking and tree of objects for each mm/mmu_notifier. v15: Prevent overlapping userptr objects, and invalidate all objects within the mmu_notifier range v16: Fix a typo for iterating over multiple objects in the range and rearrange error path to destroy the mmu_notifier locklessly. Also close a race between invalidate_range and the get_pages_worker. v17: Close a race between get_pages_worker/invalidate_range and fresh allocations of the same userptr range - and notice that struct_mutex was presumed to be held when during creation it wasn't. v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory for the struct sg_table and to clear it before reporting an error. v19: Always error out on read-only userptr requests as we don't have the hardware infrastructure to support them at the moment. v20: Refuse to implement read-only support until we have the required infrastructure - but reserve the bit in flags for future use. v21: use_mm() is not required for get_user_pages(). It is only meant to be used to fix up the kernel thread's current->mm for use with copy_user(). v22: Use sg_alloc_table_from_pages for that chunky feeling v23: Export a function for sanity checking dma-buf rather than encode userptr details elsewhere, and clean up comments based on suggestions by Bradley. Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Brad Volkin <bradley.d.volkin@intel.com> [danvet: Frob ioctl allocation to pick the next one - will cause a bit of fuss with create2 apparently, but such are the rules.] [danvet2: oops, forgot to git add after manual patch application] [danvet3: Appease sparse.] Signed-off-by:
-
Mika Kuoppala authored
Bit 31 in GEN6_PMINTRMSK is not an interrupt disable bit with gen8. Reviewed-by:
-
Oscar Mateo authored
Otherwise, we do a NULL pointer dereference. I've seen this happen while handling an error in i915_gem_object_pin_to_display_plane(): If i915_gem_object_set_cache_level() fails, we call is_pin_display() to handle the error. At this point, the object is still not pinned to GGTT and maybe not even bound, so we have to check before we dereference its GGTT vma. The IGT kms_flip/bo-too-big tests for this bug. v2: Chris Wilson says restoring the old value is easier, but that is_pin_display is useful as a theory of operation. Take the solomonic decision: at least this way is_pin_display is a little more robust (until Chris can kill it off). v3: Chris suggests the WARN in i915_gem_obj_to_ggtt has outlived its usefulness: add a reminder to remove it. Issue: VIZ-3772 Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Testcase: igt/kms_flip/bo-too-big Reviewed-by:
-
Daniel Vetter authored
All the callbacks are gone now. Reviewed-by:
-
Daniel Vetter authored
Looking at our current dsi driver I note that: - We don't have any slave driver right now. - There's zero support for the hardware state readout and cross check code. - All the modeset state seems to be tracked in the intel_dsi structure instead of the pipe config. Given all that I can't properly audit the dsi ->mode_set callback. So just do it as the first thing in the ->pre_pll_enable hook and hope for the best. Reviewed-by:
-
Daniel Vetter authored
A bit more care required here since there are some very few things between the call to encoder->mode_set and encoder->pre_enable. But they're either book-keeping or only matter for the vga port on the pch. So of no concern. Note that with the new sequence we write the infoframes after selecting the clock source, but that shouldn't matter. I've simply opted for this to have simpler code. Reviewed-by:
-
Daniel Vetter authored
All the hard work was already done, only thing left to do is remove the empty callback. And a now rather misleading comment I've spotted while reading through code. Reviewed-by:
-
Daniel Vetter authored
Similar to dp the only thing we do is call intel_write_eld and prepare a bit of state for the enable hooks. The only difference is that we write that to the hardware instead of keeping track of it somewhere in software. Still we can just move all this to the very first enable hook. Reviewed-by:
Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by:
-
