- 29 Jun, 2016 5 commits
-
-
Tvrtko Ursulin authored
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:Tvrtko 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:
Chris 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 authored
Required to enable correct wait_for_atomic checks. Signed-off-by:
-
Jani Nikula authored
Most notably eDP, DSI, and TV. Add MISSING_CASE handling so we won't miss this in the future. Reviewed-and-tested-by:
Peter Wu <peter@lekensteyn.nl> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/5773794027ea0d699052a343491b52343ba30504.1465810007.git.jani.nikula@intel.com
-
Jani Nikula authored
No functional changes. Reviewed-and-tested-by:
-
Jani Nikula authored
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:
-
- 28 Jun, 2016 8 commits
-
-
Rodrigo Vivi authored
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1466718636-19675-2-git-send-email-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
The spec has been updated adding new PCI IDs. Signed-off-by:
-
Imre Deak authored
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:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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:
-
Matt Roper authored
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:
Matt 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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Randy Dunlap authored
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:
Randy 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:
-
- 27 Jun, 2016 3 commits
-
-
Patrik Jakobsson authored
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:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Acked-by:
Mika Kuoppala <mika.kuoppala@intel.com> Acked-by:
-
Dave Gordon authored
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:Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (previous version) Reviewed-by:
-
Dave Gordon authored
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:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- 24 Jun, 2016 24 commits
-
-
Chris Wilson authored
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:
Joonas 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 authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Frank Binns authored
Stop claiming that UMS support is disabled when it's not actually supported anymore. Signed-off-by:
Frank Binns <frank.binns@imgtec.com> Reviewed-by:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
Daniel 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 authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
Currently setting up the backlight for a panel is sometimes done together with initialising the panel, and sometimes after the connector is registered. The backlight setup does not depend upon connector registration (i.e. access to sysfs/debugfs and the kobject hierachy) so perform it consistently just after panel initialisation. Note the discrepancy here as destroying the panel is done during connector unregistration... Signed-off-by:
-
Tvrtko Ursulin authored
Effectively removes one layer of indirection between the mask of possible engines and the engine constructors. Instead of spelling out in code the mapping of HAS_<engine> to constructors, makes more use of the recently added data driven approach by putting engine constructor vfuncs into the table as well. Effect is fewer lines of source and smaller binary. At the same time simplify the error handling since engine destructors can run on unitialized engines anyway. Similar approach could be done for legacy submission is wanted. v2: Removed ugly BUILD_BUG_ONs in favour of newly introduced ENGINE_MASK and HAS_ENGINE macros. Also removed the forward declarations by shuffling functions around. v3: Warn when logical_rings table does not contain enough data and disable the engines which could not be initialized. (Chris Wilson) v4: Chris Wilson suggested a nicer engine init loop. Signed-off-by: -
Daniel Vetter authored
Backmerge drm-next for the reworked device register/unregistering. Chris Wilson needs that to be able to land his i915 load/unload demidlayering. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
