- 28 Oct, 2016 38 commits
-
-
Chris Wilson authored
In preparation to support many distinct timelines, we need to expand the activity tracking on the GEM object to handle more than just a request per engine. We already use the struct reservation_object on the dma-buf to handle many fence contexts, so integrating that into the GEM object itself is the preferred solution. (For example, we can now share the same reservation_object between every consumer/producer using this buffer and skip the manual import/export via dma-buf.) v2: Reimplement busy-ioctl (by walking the reservation object), postpone the ABI change for another day. Similarly use the reservation object to find the last_write request (if active and from i915) for choosing display CS flips. Caveats: * busy-ioctl: busy-ioctl only reports on the native fences, it will not warn of stalls (in set-domain-ioctl, pread/pwrite etc) if the object is being rendered to by external fences. It also will not report the same busy state as wait-ioctl (or polling on the dma-buf) in the same circumstances. On the plus side, it does retain reporting of which *i915* engines are engaged with this object. * non-blocking atomic modesets take a step backwards as the wait for render completion blocks the ioctl. This is fixed in a subsequent patch to use a fence instead for awaiting on the rendering, see "drm/i915: Restore nonblocking awaits for modesetting" * dynamic array manipulation for shared-fences in reservation is slower than the previous lockless static assignment (e.g. gem_exec_lut_handle runtime on ivb goes from 42s to 66s), mainly due to atomic operations (maintaining the fence refcounts). * loss of object-level retirement callbacks, emulated by VMA retirement tracking. * minor loss of object-level last activity information from debugfs, could be replaced with per-vma information if desired Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-21-chris@chris-wilson.co.uk
-
Chris Wilson authored
Having moved the locked phase of freeing an object to a separate worker, we can now declare to the core that we only need the unlocked variant of driver->gem_free_object, and can use the simple unreference internally. Signed-off-by:
-
Chris Wilson authored
We want to hide the latency of releasing objects and their backing storage from the submission, so we move the actual free to a worker. This allows us to switch to struct_mutex freeing of the object in the next patch. Furthermore, if we know that the object we are dereferencing remains valid for the duration of our access, we can forgo the usual synchronisation barriers and atomic reference counting. To ensure this we defer freeing an object til after an RCU grace period, such that any lookup of the object within an RCU read critical section will remain valid until after we exit that critical section. We also employ this delay for rate-limiting the serialisation on reallocation - we have to slow down object creation in order to prevent resource starvation (in particular, files). v2: Return early in i915_gem_tiling() ioctl to skip over superfluous work on error. Signed-off-by:
-
Chris Wilson authored
As we can locklessly (well struct_mutex-lessly) acquire the backing storage, do so in set-domain-ioctl to reduce the contention on the struct_mutex. Signed-off-by:
-
Chris Wilson authored
We only need struct_mutex within pwrite for a brief window where we need to serialise with rendering and control our cache domains. Elsewhere we can rely on the backing storage being pinned, and forgive userspace any races against us. Signed-off-by:
-
Chris Wilson authored
We only need struct_mutex within pread for a brief window where we need to serialise with rendering and control our cache domains. Elsewhere we can rely on the backing storage being pinned, and forgive userspace any races against us. Signed-off-by:
-
Chris Wilson authored
Use the per-object mm.lock to allocate the backing storage (and hold a reference to it across the dmabuf access) without resorting to struct_mutex. Signed-off-by:
-
Chris Wilson authored
Break the allocation of the backing storage away from struct_mutex into a per-object lock. This allows parallel page allocation, provided we can do so outside of struct_mutex (i.e. set-domain-ioctl, pwrite, GTT fault), i.e. before execbuf! The increased cost of the atomic counters are hidden behind i915_vma_pin() for the typical case of execbuf, i.e. as the object is typically bound between execbufs, the page_pin_count is static. The cost will be felt around set-domain and pwrite, but offset by the improvement from reduced struct_mutex contention. Signed-off-by:
-
Chris Wilson authored
The plan is to move obj->pages out from under the struct_mutex into its own per-object lock. We need to prune any assumption of the struct_mutex from the get_pages/put_pages backends, and to make it easier we pass around the sg_table to operate on rather than indirectly via the obj. Signed-off-by:
-
Chris Wilson authored
The plan is to make obtaining the backing storage for the object avoid struct_mutex (i.e. use its own locking). The first step is to update the API so that normal users only call pin/unpin whilst working on the backing storage. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Chris Wilson authored
We can use the radixtree index of the obj->pages to find the start position of the desired partial range. Signed-off-by:
-
Chris Wilson authored
A while ago we switched from a contiguous array of pages into an sglist, for that was both more convenient for mapping to hardware and avoided the requirement for a vmalloc array of pages on every object. However, certain GEM API calls (like pwrite, pread as well as performing relocations) do desire access to individual struct pages. A quick hack was to introduce a cache of the last access such that finding the following page was quick - this works so long as the caller desired sequential access. Walking backwards, or multiple callers, still hits a slow linear search for each page. One solution is to store each successful lookup in a radix tree. v2: Rewrite building the radixtree for clarity, hopefully. v3: Rearrange execbuf to avoid calling i915_gem_object_get_sg() from within an atomic section and so relax the allocation context to a simple GFP_KERNEL and mutex. Signed-off-by:
-
Chris Wilson authored
Add lockdep_assert_held(struct_mutex) to the API preamble of the internal GEM interfaces. Signed-off-by:
-
Chris Wilson authored
The golden render state is constant, but we recreate the batch setting it up for every new context. If we keep that batch in a volatile cache we can safely reuse it whenever we need to initialise a new context. We mark the pages as purgeable and use the shrinker to recover pages from the batch whenever we face memory pressues, recreating that batch afresh on the next new context. Signed-off-by:
Joonas Lahtinen <joonas.lahtien@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-8-chris@chris-wilson.co.uk
-
Chris Wilson authored
Quite a few of our objects used for internal hardware programming do not benefit from being swappable or from being zero initialised. As such they do not benefit from using a shmemfs backing storage and since they are internal and never directly exposed to the user, we do not need to worry about providing a filp. For these we can use an drm_i915_gem_object wrapper around a sg_table of plain struct page. They are not swap backed and not automatically pinned. If they are reaped by the shrinker, the pages are released and the contents discarded. For the internal use case, this is fine as for example, ringbuffers are pinned from being written by a request to be read by the hardware. Once they are idle, they can be discarded entirely. As such they are a good match for execlist ringbuffers and a small variety of other internal objects. In the first iteration, this is limited to the scratch batch buffers we use (for command parsing and state initialisation). v2: Allocate physically contiguous pages, where possible. v3: Reduce maximum order on subsequent requests following an allocation failure. v4: Fix up mismatch between swiotlb segment size and page count (it counts in 2k units, not 4k pages) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-7-chris@chris-wilson.co.uk
-
Chris Wilson authored
We only need the active reference to keep the object alive after the handle has been deleted (so as to prevent a synchronous gem_close). Why then pay the price of a kref on every execbuf when we can insert that final active ref just in time for the handle deletion? Signed-off-by:
-
Chris Wilson authored
Since we only use the more generic unlocked variant, just rename it as the normal i915_gem_active_wait(). The temporary cost is that we need to always acquire the reference in a RCU safe manner, but the benefit is that we will combine the common paths. Signed-off-by:
-
Chris Wilson authored
Our low-level wait routine has evolved from our generic wait interface that handled unlocked, RPS boosting, waits with time tracking. If we push our GEM fence tracking to use reservation_objects (required for handling multiple timelines), we lose the ability to pass the required information down to i915_wait_request(). However, if we push the extra functionality from i915_wait_request() to the individual callsites (i915_gem_object_wait_rendering and i915_gem_wait_ioctl) that make use of those extras, we can both simplify our low level wait and prepare for extending the GEM interface for use of reservation_objects. v2: Rewrite i915_wait_request() kerneldocs Signed-off-by:
-
Chris Wilson authored
The throttle-ioctl never touches the struct_mutex. It does, however, as part of its ABI report whether the hardware is terminally wedged. For that purposes, it only has to report the current state and not incur the cost of checking/waiting every invocation, as we do not have to wait for a reset before waiting on a request to ensure completion (that is baked into the wait request implementation). Signed-off-by:
-
Chris Wilson authored
In forthcoming patches, we want to be able to dynamically allocate the wait_queue_t used whilst awaiting. This is more convenient if we extend the i915_sw_fence_await_sw_fence() to perform the allocation for us if we pass in a gfp mask as an alternative than a preallocated struct. Signed-off-by:
-
Chris Wilson authored
We will need to wait on DMA completion (as signaled via struct fence) before executing our i915_gem_request. Therefore we want to expose a method for adding the await on the fence itself to the request. v2: Add a comment detailing a failure to handle a signal-on-any fence-array. v3: Pretend that magic numbers don't exist. Signed-off-by:
-
Chris Wilson authored
We are not allowed to touch the GTT entries underneath an atomic section, as they take a rpm wakelock (which is illegal from atomic context) and in the near future acquiring the DMA address for a page within an object may sleep for an allocation. This makes the current shortcircuit in relocation_iomap() for performing a second relocation on an adjacent page illegal, and we need to release the atomic iomapping, lookup the DMA, insert it into the GTT before reentering the atomic iomap section. As it happens, this is precisely what we do on if we are using an iomapping over the full object and not just a single page and by removing the shortcut, we do the right thing. Fixes: 9c870d03 ("drm/i915: Use RPM as the barrier for controlling...") Signed-off-by:
-
Matt Roper authored
This was the only use of (misleadingly-named) intel_num_planes() function, so we can remove it as well. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477522291-10874-3-git-send-email-matthew.d.roper@intel.comReviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com>
-
Matt Roper authored
This macro's name is a bit misleading; it doesn't actually iterate over all planes since it omits the cursor plane. Its only uses are in gen9 code which is using it to iterate over the universal planes (which we treat as primary+sprites); in these cases the legacy cursor registers are programmed independently if necessary. The macro's iterator value (0 for primary plane, spritenum+1 for each secondary plane) also isn't meaningful outside the gen9 context where the hardware considers them to all be "universal" planes that follow this numbering. This is just a renaming/clarification patch with no functional change. However it will make the subsequent patches more clear. Signed-off-by:
-
Navare, Manasi D authored
These static helper functions are required to be used during fallback link rate implemnetation so they need to be placed at the top of the file. v3: * Add cleanup to other patch (Mika Kahola) v2: * Dont move around functions declared in intel_drv.h (Rodrigo Vivi) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1477524358-16563-4-git-send-email-manasi.d.navare@intel.com
-
Ander Conselvan de Oliveira authored
The port registers related to the phys in broxton map to different channels and specific phys. Make that mapping explicit. v2: Pass enum dpio_phy to macros instead of mmio base. (Imre) v3: Fix typo in macros. (Imre) v4: Also change variables from u32 to enum dpio_phy. (Imre) Remove leftovers from previous version. (Imre) v5: Actually git add the changes. Signed-off-by:Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1476863940-6019-1-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Use struct bxt_ddi_phy_info to hold information of where the Rcomp resistor is located, instead of hard coding it in the init sequence. Note that this moves the enabling of the phy with the Rcomp resistor out of the power well enable code. That should be safe since bxt_ddi_phy_init() is called while the power domains lock is held, and that is the only way that function gets called, so there is no possibility of a concurrent phy enable caused by a power domain get call. v2: Replace comment about lock with lockdep_assert_held() (Imre) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Information about which phy is dual channel is hardcoded in the phy init sequence. Split that to a separate struct so the init sequence is more generic. v2: Restore mangled part that ended up in following patch. (Imre) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The vswing sequence is related to the DPIO phy, so move it closer to the rest of DPIO phy related code. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Move the DPIO phy documentation section to intel_dpio_phy.c, since that is a more suitable place now that there is a source file dedicated for those phys. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The phy in broxton is also a dpio phy, similar to cherryview but with programming through MMIO. So move the code together with the other similar phys. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Pass lane count to bxt_ddi_phy_calc_lane_optmin_mask() instead of having it extract that number from a pipe_config to decouple the phy code from intel_crtc_state. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The mapping from the BXT_DPIO_CMN_* power wells to their respective phys required a detour implemented in the bxt_power_well_to_phy() function. Instead, embed that information directly into the power_well struct, by resurrecting the data field. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Calling it data seems to imply arbitrary data can be associated with the power well. However, that field is used for look ups and expected to be unique, so rename it. Signed-off-by:
-
Daniel Vetter authored
Backmerge latest drm-next to pull in the s/fence/dma_fence/ rework, needed before we merge more i915 fencing patches. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
git://github.com/skeggsb/linuxDave Airlie authored
Karol's work which greatly improves volt/clock changes on a heap of boards, nothing too exciting beyond a random collection of fixes. * 'linux-4.9' of git://github.com/skeggsb/linux: (33 commits) drm/nouveau/fb/nv50: defer DMA mapping of scratch page to oneinit() hook drm/nouveau/fb/gf100: defer DMA mapping of scratch page to oneinit() hook drm/nouveau/pci: set streaming DMA mask early drm/nouveau/kms: add Maxwell to backlight initialization drm/nouveau/bar/nv50: fix bar2 vm size drm/nouveau/disp: remove unused function in sorg94.c drm/nouveau/volt: use kernel's 64-bit signed division function drm/nouveau/core: add missing header dependencies drm/nouveau/gr/nv3x: add 0x0597 kelvin 3d class support drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo drm/nouveau/fb/ram: Use Kepler implementation on Maxwell drm/nouveau/volt: Make use of cvb coefficients drm/nouveau/volt/gf100-: Add speedo drm/nouveau/volt: Add implementation for gf100 drm/nouveau/bios/vmap: unk0 field is the mode drm/nouveau/volt: Don't require perfect fit drm/nouveau/clk: Allow boosting only when NvBoost is set drm/nouveau/bios: Add parsing of VPSTATE table drm/nouveau/clk: Respect voltage limits in nvkm_cstate_prog drm/nouveau/clk: Fixup cstate selection ...
-
git://anongit.freedesktop.org/git/drm-intelDave Airlie authored
Pull request already again to get the s/fence/dma_fence/ stuff in and allow everyone to resync. Otherwise really just misc stuff all over, and a new bridge driver. * tag 'topic/drm-misc-2016-10-27' of git://anongit.freedesktop.org/git/drm-intel: drm/bridge: fix platform_no_drv_owner.cocci warnings drm/bridge: fix semicolon.cocci warnings drm: Print some debug/error info during DP dual mode detect drm: mark drm_of_component_match_add dummy inline drm/bridge: add Silicon Image SiI8620 driver dt-bindings: add Silicon Image SiI8620 bridge bindings video: add header file for Mobile High-Definition Link (MHL) interface drm: convert DT component matching to component_match_add_release() dma-buf: Rename struct fence to dma_fence dma-buf/fence: add an lockdep_assert_held() drm/dp: Factor out helper to distinguish between branch and sink devices drm/edid: Only print the bad edid when aborting drm/msm: add missing header dependencies drm/msm/adreno: move function declarations to header file drm/i2c/tda998x: mark symbol static where possible doc: add missing docbook parameter for fence-array drm: RIP mode_config->rotation_property drm/msm/mdp5: Advertize 180 degree rotation drm/msm/mdp5: Use per-plane rotation property
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
First new feature pull for 4.10. Highlights: - Support for multple virtual displays in the virtual dce component - New VM mgr to support non-contiguous vram buffers - Support for UVD powergating on additional asics - Power management improvements - lots of code cleanup and bug fixes * 'drm-next-4.10' of git://people.freedesktop.org/~agd5f/linux: (107 commits) drm/amdgpu: turn on/off uvd clock when dpm enable/disable on CI drm/amdgpu: disable dpm before turn off clock when vce idle. drm/amdgpu: enable uvd bypass mode for CI/VI. drm/amdgpu: just not load smc firmware if smu is already running drm/amdgpu: when suspend, set boot state instand of disable dpm. drm/amdgpu: use failed label to handle context init failure drm/amdgpu: add amdgpu_ttm_bo_eviction_valuable callback drm/ttm: make eviction decision a driver callback v2 drm/ttm: fix coding style in ttm_bo_driver.h drm/radeon/pm: autoswitch power state when in balanced mode drm/amd/powerplay: fix spelling mistake and add KERN_WARNING to printks drm/amdgpu:new ids flag for preempt drm/amdgpu: mark symbols static where possible drm/amdgpu: change function declarations and add missing header dependencies drm/amdgpu: s/amdgpuCrtc/amdgpu_crtc/ in pageflip code drm/amdgpu/atom: remove a bunch of unused functions drm/amdgpu: consolidate atom scratch reg handling for hangs drm/amdgpu: use amdgpu_bo_[create|free]_kernel for wb drm/amdgpu: add VCE VM session tracking drm/amdgpu: improve parse_cs handling a bit ...
-
- 27 Oct, 2016 2 commits
-
-
Rex Zhu authored
Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Rex Zhu authored
v2: move return value check as well Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
