- 30 6月, 2016 3 次提交
-
-
由 Chris Wilson 提交于
Ville Syrjälä reported that in the majority of wait_for(I915_READ()) he inspect, most completed within the first couple of reads and that the delay between those wait_for() reads was the ratelimiting step for many code paths. For example, __gen6_update_ring_freq() was blamed for slowing down boot by many milliseconds, but under Ville's scrutiny the issue was just excessive delay waiting for sandybridge_pcode_write(). We can eliminate the wait by initially using a busyspin upon the register read and only fallback to the sleeping loop in cases where the hardware is indeed too slow. A threshold of 2 microseconds is used as the initial ballpark. To avoid excessive code bloating from converting every wait_for() into a hybrid busy/sleep loop, we extend wait_for_register_fw() and export it for use by other callers. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467297225-21379-1-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
This reverts commit ee042aa4. Something appears to be off in the timing, but as far as I can tell it is not along the event delivery path. The net effect appears to be rendering flicker (the current render buffer appears on the scanout, with what appears to be active rendering for a fraction of a frame) and is causing me a headache. The cursor is also being stalled by page flips, causing a "heavy mouse" and jitter. Daniel Stone did find what appears to the cause of the tearing, in https://lists.freedesktop.org/archives/intel-gfx/2016-June/099466.html That is the parameter passed to intel_atomic_commit_tail is the old_state but we need the new_state to wait upon. That leaves the question of how the CRC based tests didn't spot the error (how can we improve our tests?), the issue of legacy cursor stalling flips, and the issue of flips stalling the cursor. For the moment, step back until the condundrum of new/old state is reviewed along with more tests! Reported-and-tested-by: NSteven Newbury <steve@snewbury.org.uk> Reported-by: NRafael Ristovski <rafael.ristovski@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96593 Testcase: igt/kms_cursor_legacy/basic-cursor-vs-flip Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466772243-21879-1-git-send-email-chris@chris-wilson.co.ukAcked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Chris Wilson 提交于
Since commit 2ed53a94 ("drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno") once a hang is completed, the seqno is advanced past all current requests. With this we know that if we wake up from waiting for a request, if a hang has occurred and reset completed, our request will be considered complete (i.e. i915_gem_request_completed() returns true). Therefore we only need to worry about the situation where a hang has occurred, but not yet reset, where we may need to release our struct_mutex. Since we don't need to detect the completed reset using the global gpu_error->reset_counter anymore, we do not need to track the reset_counter epoch inside the request. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467211874-11552-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: NArun Siluvery <arun.siluvery@linux.intel.com>
-
- 29 6月, 2016 12 次提交
-
-
由 Tvrtko Ursulin 提交于
usleep_range is not recommended for waits shorten than 10us. Make the wait_for_us use the atomic variant for such waits. To do so we need to reimplement the _wait_for_atomic macro to be safe with regards to preemption and interrupts. v2: Reimplement _wait_for_atomic to be irq and preemption safe. (Chris Wilson and Imre Deak) v3: Fixed in_atomic check due rebase error. v4: Build bug on non-constant timeouts. v5: Compile away cpu migration code in atomic paths. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1467114710-29989-1-git-send-email-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Required to enable correct wait_for_atomic checks. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Jani Nikula 提交于
Most notably eDP, DSI, and TV. Add MISSING_CASE handling so we won't miss this in the future. Reviewed-and-tested-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/5773794027ea0d699052a343491b52343ba30504.1465810007.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
No functional changes. Reviewed-and-tested-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/ef19172e5a00d8abd8190a5389283ef6b5f7eaa9.1465810007.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
It's easier to read the code when the macro names match the spec. Also add a bunch of missing ones. No functional changes. Reviewed-and-tested-by: NPeter Wu <peter@lekensteyn.nl> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7cfdd2733b8cc7abae43cfa8c81aed902b69ecd5.1465810007.git.jani.nikula@intel.com
-
由 Rodrigo Vivi 提交于
This is unusual. Usually IDs listed on early stages of platform definition are kept there as reserved for later use. However these IDs here are not listed anymore in any of steppings and devices IDs tables for Kabylake on configurations overview section of BSpec. So it is better removing them before they become used in any other future platform. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466718636-19675-2-git-send-email-rodrigo.vivi@intel.com
-
由 Rodrigo Vivi 提交于
The spec has been updated adding new PCI IDs. Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466718636-19675-1-git-send-email-rodrigo.vivi@intel.com
-
由 Imre Deak 提交于
Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Due to the relatively long 10ms timeout, probably this didn't cause any real problems, but fix it in any case for consistency. Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity") CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> CC: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-5-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity") CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> CC: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-4-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity") CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> CC: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-3-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
Since wait_for_atomic doesn't re-check the wait-for condition after expiry of the timeout it can fail when called from non-atomic context even if the condition is set correctly before the expiry. Fix this by using the non-atomic wait_for instead. I noticed this via the PLL locking timing out incorrectly, with this fix I couldn't reproduce the problem. Fixes: 0351b939 ("drm/i915: Do not lie about atomic timeout granularity") CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> CC: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/1467110253-16046-2-git-send-email-imre.deak@intel.com
-
由 Matt Roper 提交于
When a display update triggers a DDB re-allocation, we should start by assuming that only the updated pipes need to be re-allocated (we have logic later that may add additional pipes if, e.g., a modeset triggers a change to the global allocation). We were erroneously using the _active_ pipes as our starting point rather than the changed pipes. This causes us to grab CRTC locks that we didn't actually need, reducing parallelism. Given the recent non-blocking atomic changes, it also causes legacy pageflips against one CRTC to return -EBUSY if there's an outstanding pageflip against a different CRTC (a situation easily triggered via compositors like Weston). Fixes: 98d39494 ("drm/i915/gen9: Compute DDB allocation at atomic check time (v4)") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467070964-14864-1-git-send-email-matthew.d.roper@intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
- 28 6月, 2016 2 次提交
-
-
由 Randy Dunlap 提交于
Fix build errors when ACPI is not enabled by adding function stubs: ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend': ../drivers/gpu/drm/i915/i915_drv.c:635:2: error: implicit declaration of function 'intel_opregion_unregister' [-Werror=implicit-function-declaration] intel_opregion_unregister(dev_priv); ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_resume': ../drivers/gpu/drm/i915/i915_drv.c:798:2: error: implicit declaration of function 'intel_opregion_register' [-Werror=implicit-function-declaration] intel_opregion_register(dev_priv); Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Fixes: 03d92e47 ("drm/i915/opregion: Rename init/fini functions to register/unregister") Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [Jani: dropped the stale init/fini declarations] Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1467028399-9965-1-git-send-email-jani.nikula@intel.com
-
由 Patrik Jakobsson 提交于
Load specific firmware versions for the DMC instead of using symbolic links. The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07. Certain DMC versions need workarounds in the driver which forces us to have a tight dependency between firmware and driver. In order to be able to provide a tested and known working configuration we must lock down on a specific DMC firmware version. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Acked-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1463391057-32350-1-git-send-email-patrik.jakobsson@linux.intel.com
-
- 27 6月, 2016 2 次提交
-
-
由 Dave Gordon 提交于
If a context waiting for VBlank were switched out, switching in the next context and generating a CSB event in the process, then the GuC would have to put the context back in the queue, and then observe the subsequent VBlank interrupt so that it could resubmit the suspended context. However, we always set the CTX_CTRL_INHIBIT_SYN_CTX_SWITCH bit in the RING_CONTEXT_CONTROL register, so this case cannot occur. Furthermore we don't use the GuC's internal scheduler or allow it to auto-resubmit workloads. Consequently, the GuC doesn't need to see VBlanks, and by sending them to it we may be waking it up unnecessarily, which might reduce RC6 residency and increase power consumption. So this patch removes the setting of the GFC_FORWARD_VBLANK field from the code that diverts interrupts towards the GuC. (The code to direct interrupts to the host, OTOH, continues to explicitly set the field to "never send VBlanks to the GuC".) v3: Remove the line of code completely (original set the field to ALWAYS forward, v1 changed it to CONDITIONAL forwarding, v2 explicitly set it to NEVER, v3 just doesn't touch it at all, as we know it's already set to NEVER). Signed-off-by: NDave Gordon <david.s.gordon@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (previous version) Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466780277-23435-1-git-send-email-david.s.gordon@intel.com
-
由 Dave Gordon 提交于
Gen8 versions of these macros were updated a few months ago (e8ebd8e2 drm/i915: eliminate 'temp' in gen8_for_each macros) originally because at least one iterator could generate an out of bounds access, but also because eliminating the 'temp' parameter generated smaller and faster code. Matthew Auld recently noticed the same problem with the gen6 versions and provided a patch https://lists.freedesktop.org/archives/intel-gfx/2016-June/099334.html but while we're changing these, we might as well make them as much like the gen8 versions as possible, including the style of using "&& (..., true)" rather than ": (..., 1) : 0", and of course eliminating the redundant 'temp'. Furthermore, the "all_pdes" version is only used in one place, so we can improve code efficiency by changing both the macro parameters and the calling code to reduce extra dereferences. Signed-off-by: NDave Gordon <david.s.gordon@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMatthew Auld <matthew.auld@intel.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466793466-23500-1-git-send-email-david.s.gordon@intel.com
-
- 24 6月, 2016 21 次提交
-
-
由 Chris Wilson 提交于
The contexts only pin space within the global GTT. Therefore forcing the switch to the perma-pinned kernel context only has an effect when trying to evict from and find room within the global GTT. We can then restrict the switch to only when operating on the default context. This is mostly a no-op as full-ppgtt only exists with execlists at present which skips the context switch anyway. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-7-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
We only need to force a switch to the kernel context placeholder during eviction. All other uses of i915_gpu_idle() just want to wait until existing work on the GPU is idle. Rename i915_gpu_idle() to i915_gem_wait_for_idle() to avoid any implications about "parking" the context first. v2: Tweak an error message if the wait fails for the ilk vtd w/a Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-6-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
As the L3 remapping is applied before the next execution, there is no need to wait until all previous uses are idle, the application will not occur any sooner. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-5-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
When the GPU is reset or state lost through suspend, every default legacy context needs to reload their state - both the golden render state and the L3 mapping. Only context images explicitly saved to memory (i.e. all execlists and non-default legacy contexts) will retain their state across the reset. v2: Rebase Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-4-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The kernel context exists simply as a placeholder and should never be executed with a render context. It does not need the golden render state, as that will always be applied to a user context. By skipping the initialisation we can avoid issues in attempting to program the golden render context when trying to make the hardware idle. v2: Rebase Testcase: igt/drm_module_reload_basic #byt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95634Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-3-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
This is so that we have symmetry with intel_lrc.c and avoid a source of if (i915.enable_execlists) layering violation within i915_gem_context.c - that is we move the specific handling of the dev_priv->kernel_context for legacy submission into the legacy submission code. This depends upon the init/fini ordering between contexts and engines already defined by intel_lrc.c, and also exporting the context alignment required for pinning the legacy context. v2: Separate out pin/unpin context funcs for greater symmetry with intel_lrc. One more step towards unifying behaviour between the two classes of engines and towards fixing another bug in i915_switch_context vs requests. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-2-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
During suspend (or module unload), if we have never accessed the engine (i.e. userspace never submitted a batch to it), the engine is idle. Then we attempt to idle the engine by forcing it to the default context, which actually means we submit a render batch to setup the golden context state and then wait for it to complete. We can skip this entirely as we know the engine is idle. v2: Drop incorrect comment. References: https://bugs.freedesktop.org/show_bug.cgi?id=95634Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466776558-21516-1-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The module init/exit routines are a wrapper around the PCI device init/exit, so move them across. Note that in order to avoid exporting the driver struct, instead of manipulating driver.features inside i915_init we instead opt to simply exit if i915.modeset is disabled. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-15-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
To reclaim a bit of space from i915_drv.c, we can move the routines that just hook us into the PCI device tree into i915_pci.c Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-14-git-send-email-chris@chris-wilson.co.uk
-
由 Frank Binns 提交于
Stop claiming that UMS support is disabled when it's not actually supported anymore. Signed-off-by: NFrank Binns <frank.binns@imgtec.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1466763836-27772-1-git-send-email-frank.binns@imgtec.com Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-13-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Don't emit a driver DRM_ERROR for a user passing in an invalid CRTC id, simply report it is missing back to the user. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-12-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
The GETPARAM ioctl writes to a user supplied address. If that address is invalid, it is the user's error and not the driver's, so quietly report EFAULT and don't blame ourselves with a DRM_ERROR. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-11-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
i915_dma.c used to contain the DRI1/UMS horror show, but now all that remains are the out-of-place driver level interfaces (such as allocating, initialising and registering the driver). These should be in i915_drv.c alongside similar routines for suspend/resume. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-10-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Baby step, update to_i915() conversion from drm_device to drm_i915_private: text data bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-9-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
drm_connector_register_all() is now automatically called by drm_dev_register(), and so we no longer have to do so ourselves (via intel_modeset_register() after calling drm_dev_register()). Similarly for unregistering. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-8-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
To complete the transition to manual control of load/unload, we need to take over unloading from i915_pci_remove(). This allows us to correctly order our unregister vs shutdown phases, which currently are inverted due to the midlayer. However, the unload sequence is still invalid as we shutdown the driver with the last reference. Ideally, all we want to do is remove the userspace access on device removal, deferring the cleanup to the drm_dev_release() - breaking the reference cycles is then left as an exercise for the reader. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-7-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering makes the driver visible to userspace first (in order to coordinate with removed DRI1 userspace), but that ordering incurs risk. The risk increases as we strive for more asynchronous loading. One side effect of controlling the allocation is that we can allocate both the drm_device + drm_i915_private in one block, the next step towards subclassing. Unload is still left as before, a mix of midlayer and driver. v2: After drm_dev_init(), we should call drm_dev_unref() so that we call drm_dev_release() and free everything from drm_dev_init(). v3: Fixup missed error code for failing to allocate dev_priv Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-6-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our registration phase, where we announce our presence to the world when we are ready, i.e the sequence changes from drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_debugfs_init() -> i915_driver_load() to drm_dev_register() -> drm_minor_register() -> drm_debugfs_init() -> i915_driver_load() -> i915_debugfs_register() Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-5-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-4-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-3-git-send-email-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
With the introduction of a connector->func for callback from drm_connector_register() we can move all the tasks that we want to do upon registration into that callback. Later, this will allow us to reorder the registration and defer it until after the device is setup and ready for userspace. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1466773227-7994-2-git-send-email-chris@chris-wilson.co.uk
-