- 09 1月, 2019 1 次提交
-
-
由 Jani Nikula 提交于
Needs just a few additional includes here and there. Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108082709.3748-1-jani.nikula@intel.com
-
- 03 1月, 2019 1 次提交
-
-
由 Chris Wilson 提交于
When we first introduced the reset to sanitize the GPU on taking over from the BIOS and before returning control to third parties (the BIOS!), we restricted it to only systems utilizing HW contexts as we were uncertain of how stable our reset mechanism truly was. We now have reasonable coverage across all machines that expose a GPU reset method, and so we should be safe to sanitize the GPU state everywhere. v2: We _have_ to skip the reset if it would clobber the display. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190103112104.19561-1-chris@chris-wilson.co.uk
-
- 02 1月, 2019 4 次提交
-
-
由 Jani Nikula 提交于
The debugfs, error state and regular dmesg logging dump needs seem to be different. Remove the generic dump function only used for the welcome message. This may be added back later when better abstractions are identified, but at the moment this seems to be the simplest considering the device info rework in progress. No longer rely on device info being a substruct of dev_priv. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/70ff0c7c0ec3ef8747af3c78e272b5a82be3d55b.1546267488.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
Hide the way device info is stored, in preparation of making device info a pointer to the const rodata in i915_pci.c. No functional changes. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3cd626f248c0d6638f1288938bbb577a12286050.1546267488.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
With the static/runtime device info split, this makes more sense. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ad5b448e4e318df0d292d73e6c3378f3e6b9bae5.1546267488.git.jani.nikula@intel.com
-
由 Jani Nikula 提交于
First move the low hanging fruit, the fields that are only initialized runtime. Use RUNTIME_INFO() exclusively to access the fields. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c24fe7a4b0492a888690c46814c0ff21ce2f12b1.1546267488.git.jani.nikula@intel.com
-
- 28 12月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
The writing is on the wall for the existence of a single execution queue along each engine, and as a consequence we will not be able to track dependencies along the HW queue itself, i.e. we will not be able to use HW semaphores on gen7 as they use a global set of registers (and unlike gen8+ we can not effectively target memory to keep per-context seqno and dependencies). On the positive side, when we implement request reordering for gen7 we also can not presume a simple execution queue and would also require removing the current semaphore generation code. So this bring us another step closer to request reordering for ringbuffer submission! The negative side is that using interrupts to drive inter-engine synchronisation is much slower (4us -> 15us to do a nop on each of the 3 engines on ivb). This is much better than it was at the time of introducing the HW semaphores and equally important userspace weaned itself off intermixing dependent BLT/RENDER operations (the prime culprit was glyph rendering in UXA). So while we regress the microbenchmarks, it should not impact the user. References: https://bugs.freedesktop.org/show_bug.cgi?id=108888Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181228140736.32606-2-chris@chris-wilson.co.uk
-
- 13 12月, 2018 2 次提交
-
-
由 Chris Wilson 提交于
After declaring a terminally wedged device, we allow ourselves to recover on the next GPU reset (manually triggered), or resume. Check that resetting a wedged device does work. v2: Add rpm (taken explicitly in the subtest in case we remove the outer wakeref) and early warning to i915_reset() for missed wakerefs Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181213091522.2926-1-chris@chris-wilson.co.uk
-
由 Lucas De Marchi 提交于
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of gen_mask to do the comparison. Now callers can pass then gen as a parameter, so we don't require one macro for each gen. The following spatch was used to convert the users of these macros: @@ expression e; @@ ( - IS_GEN2(e) + IS_GEN(e, 2) | - IS_GEN3(e) + IS_GEN(e, 3) | - IS_GEN4(e) + IS_GEN(e, 4) | - IS_GEN5(e) + IS_GEN(e, 5) | - IS_GEN6(e) + IS_GEN(e, 6) | - IS_GEN7(e) + IS_GEN(e, 7) | - IS_GEN8(e) + IS_GEN(e, 8) | - IS_GEN9(e) + IS_GEN(e, 9) | - IS_GEN10(e) + IS_GEN(e, 10) | - IS_GEN11(e) + IS_GEN(e, 11) ) v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than using the bitmask Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
-
- 05 12月, 2018 1 次提交
-
-
由 Tvrtko Ursulin 提交于
To enable later verification of GT workaround state at various stages of driver lifetime, we record the list of applicable ones per platforms to a list, from which they are also applied. The added data structure is a simple array of register, mask and value items, which is allocated on demand as workarounds are added to the list. This is a temporary implementation which later in the series gets fused with the existing per context workaround list handling. It is separated at this stage since the following patch fixes a bug which needs to be as easy to backport as possible. Also, since in the following patch we will be adding a new class of workarounds (per engine) which can be applied from interrupt context, we straight away make the provision for safe read-modify-write cycle. v2: * Change dev_priv to i915 along the init path. (Chris Wilson) * API rename. (Chris Wilson) v3: * Remove explicit list size tracking in favour of growing the allocation in power of two chunks. (Chris Wilson) v4: Chris Wilson: * Change wa_list_finish to early return. * Copy workarounds using the compiler for static checking. * Do not bother zeroing unused entries. * Re-order struct i915_wa_list. v5: * kmalloc_array. * Whitespace cleanup. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133319.10174-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit 25d140fa) Fixes: 59b449d5 ("drm/i915: Split out functions for different kinds of workarounds") Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 04 12月, 2018 4 次提交
-
-
由 Tvrtko Ursulin 提交于
Since we now have all the GT workarounds in a table, by adding a simple shared helper function we can now verify that their values are still applied after some interesting events in the lifetime of the driver. Initially we only do this after GPU initialization. v2: Chris Wilson: * Simplify verification by realizing it's a simple xor and and. * Remove verification from engine reset path. * Return bool straight away from the verify API. v3: * API rename. (Chris Wilson) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203125014.3219-4-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
To enable later verification of GT workaround state at various stages of driver lifetime, we record the list of applicable ones per platforms to a list, from which they are also applied. The added data structure is a simple array of register, mask and value items, which is allocated on demand as workarounds are added to the list. This is a temporary implementation which later in the series gets fused with the existing per context workaround list handling. It is separated at this stage since the following patch fixes a bug which needs to be as easy to backport as possible. Also, since in the following patch we will be adding a new class of workarounds (per engine) which can be applied from interrupt context, we straight away make the provision for safe read-modify-write cycle. v2: * Change dev_priv to i915 along the init path. (Chris Wilson) * API rename. (Chris Wilson) v3: * Remove explicit list size tracking in favour of growing the allocation in power of two chunks. (Chris Wilson) v4: Chris Wilson: * Change wa_list_finish to early return. * Copy workarounds using the compiler for static checking. * Do not bother zeroing unused entries. * Re-order struct i915_wa_list. v5: * kmalloc_array. * Whitespace cleanup. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181203133319.10174-1-tvrtko.ursulin@linux.intel.com
-
由 José Roberto de Souza 提交于
Right now it is decided if GEN has display by checking the num_pipes, so lets make it explicit and use a macro. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130232048.14216-1-jose.souza@intel.com
-
由 Chris Wilson 提交于
Since commit fd8526e5 ("drm/i915/execlists: Trust the CSB") we actually broke the force-mmio mode for our execlists implementation. No one noticed, so ergo no one is actually using an old vGPU host (where we required the older method) and so can simply remove the broken support. v2: csb_read can go as well (Mika) Reported-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Fixes: fd8526e5 ("drm/i915/execlists: Trust the CSB") 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: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181130125954.11924-1-chris@chris-wilson.co.uk
-
- 29 11月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
Mark A0 as the one and only pre-production variant of Kabylake and remove its couple of workarounds, consigning them to the annals of history. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181128135325.10641-1-chris@chris-wilson.co.uk
-
- 09 11月, 2018 4 次提交
-
-
由 José Roberto de Souza 提交于
All other overlay functions(almost all other functions in i915) follow intel_overlay_verb, so renaming overlay ones that do not match that. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-4-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
IPC is a display feature, so i915_load_modeset_init() is the right place to initialize it. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-3-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
Although FBC helps save power it do not belongs to power management also the cleanup was placed in i915_driver_unload() also not a good place. intel_modeset_init()/intel_modeset_cleanup() are better places also this will help make easy disable features that depends in display being enabled in driver. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-2-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
i915_load_modeset_init() is a more suitable place than i915_driver_load() as vblank is part of modeset. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181108001647.11276-1-jose.souza@intel.com
-
- 06 11月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to the appropriate platforms. This was especially harsh on GLK since we don't even try to read the DIMM information on that platforms, hence valid_dimm was always false and thus we always tried to apply the w/a. Furthermore the w/a pushed the level 0 latency above the level 1 latency, which doesn't really make sense. v2: Do the check when populating is_16gb_dimm (Mahesh) Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 86b59287 ("drm/i915: Implement 16GB dimm wa for latency level-0") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023182102.31549-1-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMahesh Kumar <mahesh1.sh.kumar@gmail.com> (cherry picked from commit 5d6f36b2) Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 02 11月, 2018 1 次提交
-
-
由 Anusha Srivatsa 提交于
Add missing block that takes care of inline intel_suspend_complete for DC9 on ICL. Daniele noticed this was part of original patch but missed on on merged commit ("drm/i915/icl: Enable DC9 as lowest possible state during screen-off"). Fixes: 3e68928b ("drm/i915/icl: Enable DC9 as lowest possible state during screen-off") Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: James Ausmus <james.ausmus@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo added a commit message while merging] Link: https://patchwork.freedesktop.org/patch/msgid/20181031202726.4021-1-anusha.srivatsa@intel.com
-
- 31 10月, 2018 1 次提交
-
-
由 Animesh Manna 提交于
ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable DC5/6 when appropriate. v2: (James Ausmus) - Also handle ICL as GEN9_LP in i915_drm_suspend_late and i915_drm_suspend_early - Add DC9 to gen9_dc_mask for ICL - Re-order GEN checks for newest platform first - Use INTEL_GEN instead of INTEL_INFO->gen - Use INTEL_GEN >= 11 instead of IS_ICELAKE - Consolidate GEN checks v3: (James Ausmus) - Also allow DC6 for ICL (Imre, Art) - Simplify !(GEN >= 11) to GEN < 11 (Imre) v4: (James Ausmus) - Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the PPS regs are Always On - Rebase against upstream changes v5: (Anusha Srivatsa) - rebased against the latest upstream changes. v6: (Anusha Srivatsa) - rebased.Use INTEL_GEN consistently. - Simplify the code (Rodrigo) v7: rebased. Change order according to platforms(Jyoti) v8: rebased. Change the check from platform specific to HAS_PCH_SPLIT(). Add comment in code to be more clear.(Rodrigo) Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NAnimesh Manna <animesh.manna@intel.com> Signed-off-by: NJames Ausmus <james.ausmus@intel.com> Signed-off-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Tested-by: NJyoti Yadav <jyoti.r.yadav@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181029221410.4423-1-anusha.srivatsa@intel.com
-
- 30 10月, 2018 2 次提交
-
-
由 Chris Wilson 提交于
If we reduce the suspend function for intel_opregion to do the minimum required, the resume function can also do the simple task of notifier the ACPI bios that we are back. This avoid some nasty restrictions on the likes of register_acpi_notifier() that are not allowed during the early phase of resume. v2: Keep the order of acpi notify vs turning off ardy/drdy the same. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Acked-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181030110554.4111-1-chris@chris-wilson.co.uk
-
由 Rodrigo Vivi 提交于
Whenever possible we should stick with IS_GEN<n> checks. Bitmaks has been introduced on commit ae7617f0 ("drm/i915: Allow optimized platform checks") for efficiency. Let's stick with it whenever possible. This patch was generated with coccinelle: spatch -sp_file is_gen.cocci *{c,h} --in-place is_gen.cocci: @gen2@ expression e; @@ -INTEL_GEN(e) == 2 +IS_GEN2(e) @gen3@ expression e; @@ -INTEL_GEN(e) == 3 +IS_GEN3(e) @gen4@ expression e; @@ -INTEL_GEN(e) == 4 +IS_GEN4(e) @gen5@ expression e; @@ -INTEL_GEN(e) == 5 +IS_GEN5(e) @gen6@ expression e; @@ -INTEL_GEN(e) == 6 +IS_GEN6(e) @gen7@ expression e; @@ -INTEL_GEN(e) == 7 +IS_GEN7(e) @gen8@ expression e; @@ -INTEL_GEN(e) == 8 +IS_GEN8(e) @gen9@ expression e; @@ -INTEL_GEN(e) == 9 +IS_GEN9(e) @gen10@ expression e; @@ -INTEL_GEN(e) == 10 +IS_GEN10(e) @gen11@ expression e; @@ -INTEL_GEN(e) == 11 +IS_GEN11(e) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181026195143.20353-1-rodrigo.vivi@intel.com
-
- 24 10月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
The 16Gb DIMM w/a is not applicable to BXT or GLK. Limit it to the appropriate platforms. This was especially harsh on GLK since we don't even try to read the DIMM information on that platforms, hence valid_dimm was always false and thus we always tried to apply the w/a. Furthermore the w/a pushed the level 0 latency above the level 1 latency, which doesn't really make sense. v2: Do the check when populating is_16gb_dimm (Mahesh) Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 86b59287 ("drm/i915: Implement 16GB dimm wa for latency level-0") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181023182102.31549-1-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NMahesh Kumar <mahesh1.sh.kumar@gmail.com>
-
- 12 10月, 2018 1 次提交
-
-
由 Michal Wajdeczko 提交于
In case of the error we missed to call i915_mmio_cleanup that matches earlier call to i915_mmio_setup. Signed-off-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181011130008.24640-1-michal.wajdeczko@intel.com
-
- 02 10月, 2018 1 次提交
-
-
由 Andi Shyti 提交于
During driver load it's considered that the i915_driver_create() function fails only in case of insufficient memory. Indeed, in case of failure of i915_driver_create(), the load function returns indiscriminately -ENOMEM ignoring the real cause of failure. In i915_driver_create() get the consistent error value from drm_dev_init() and embed it in the pointer return value. Signed-off-by: NAndi Shyti <andi.shyti@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20181002092047.14705-1-andi.shyti@intel.com
-
- 27 9月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
Now that we are confident in providing full-ppgtt where supported, remove the ability to override the context isolation. v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted. v3: s/USES/HAS/ to match usage and reject attempts to load the module on old GVT-g setups that do not provide support for full-ppgtt. v4: Insulate ABI ppGTT values from our internal enum (later plans involve moving ppGTT depth out of the enum, thus potentially breaking ABI unless we document the current values). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: NZhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926201222.5643-1-chris@chris-wilson.co.uk
-
- 26 9月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
In commit 9144d75e ("include/linux/bitops.h: introduce BITS_PER_TYPE"), we made BITS_PER_TYPE available to all and now we can use the macro to replace some open-coded computation of sizeof(T) * BITS_PER_BYTE. Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104707.17410-1-chris@chris-wilson.co.uk
-
- 14 9月, 2018 4 次提交
-
-
由 Mahesh Kumar 提交于
IPC may cause underflows if not used with dual channel symmetric memory configuration. Disable IPC for non symmetric configurations in affected platforms. Display WA #1141 Changes Since V1: - Re-arrange the code. - update wrapper to return if memory is symmetric (Rodrigo) Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-6-mahesh1.kumar@intel.com
-
由 Mahesh Kumar 提交于
Memory with 16GB dimms require an increase of 1us in level-0 latency. This patch implements the same. Bspec: 4381 changes since V1: - s/memdev_info/dram_info - make skl_is_16gb_dimm pure function Changes since V2: - make is_16gb_dimm more generic - rebase Changes since V3: - Simplify condition (Maarten) Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180831110942.9234-1-mahesh1.kumar@intel.com
-
由 Mahesh Kumar 提交于
This patch adds support to decode system memory bandwidth and other parameters for skylake and Gen9+ platforms, which will be used for arbitrated display memory bandwidth calculation in GEN9 based platforms and WM latency level-0 Work-around calculation on GEN9+. Changes Since V1: - s/memdev_info/dram_info - create a struct to hold channel info Changes Since V2: - rewrite code to adhere i915 coding style - not valid for GLK Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-3-mahesh1.kumar@intel.com
-
由 Mahesh Kumar 提交于
This patch adds support to decode system memory bandwidth and other parameters for broxton platform, which will be used for arbitrated display memory bandwidth calculation in GEN9 based platforms and WM latency level-0 Work-around calculation on GEN9+ platforms. Changes since V1: - s/memdev_info/dram_info Changes since V2: - Adhere to i915 coding style (Rodrigo) Signed-off-by: NMahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-2-mahesh1.kumar@intel.com
-
- 13 9月, 2018 1 次提交
-
-
由 Ville Syrjälä 提交于
Currently we're clearing DRIVER_ATOMIC in driver.driver_features for older platforms. This will not work correctly should we ever have a system with and old and new GPU in it. While that is not possible currently let's make the code more correct and use the per-device driver_features instead. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180913131622.17690-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 06 9月, 2018 2 次提交
-
-
由 Chris Wilson 提交于
Introduce a complementary function to i915_driver_create() to undo all that is created. Suggested-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905140921.17467-2-chris@chris-wilson.co.uk
-
由 Chris Wilson 提交于
Attach our device_info to the our i915 private on creation so that it is always available for inspection. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905140921.17467-1-chris@chris-wilson.co.uk
-
- 20 8月, 2018 1 次提交
-
-
由 Imre Deak 提交于
After commit 2cd9a689 ("drm/i915: Refactor intel_display_set_init_power() logic") it makes more sense to check the power domain/well refcounts after enabling the power domains functionality. Before that it's guaranteed that most power wells (in the INIT domain) will have a reference held, so not an interesting state. While at it also add the check after the init_hw/fini_hw, disable and suspend/resume steps. Make the test optional on a Kconfig option since it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg access for each power well may take up to 20ms. v2: - Add the state check to more spots. (Chris) v3: - During suspend check the state before deiniting display core. Afterwards DC states are disabled (and so the dc_off power well is enabled) even though we don't hold a reference on it. - Do the test conditionally based on a new Kconfig option. (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [Add DRM_I915_DEBUG_RUNTIME_PM to welcome messages] Signed-off-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180817145837.26592-1-imre.deak@intel.com
-
- 16 8月, 2018 2 次提交
-
-
由 Imre Deak 提交于
The device global init_power_on flag is somewhat arbitrary and makes debugging power refcounting problems difficult. Instead arrange things so that all display power domain get has a corresponding put call. After this change we have the following sequences: driver loading: intel_power_domains_init_hw(); <other init steps> intel_power_domains_enable(); driver unloading: intel_power_domains_disable(); <other uninit steps> intel_power_domains_fini_hw(); system suspend: intel_power_domains_disable(); <other suspend steps> intel_power_domains_suspend(); system resume: intel_power_domains_resume(); <other resume steps> intel_power_domains_enable(); at other times while the driver is loaded: intel_display_power_get(); ... intel_display_power_put(); Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-2-imre.deak@intel.com
-
由 Chris Wilson 提交于
Currently, we cancel the extra wakeref we have for !runtime-pm devices inside power_wells_fini_hw. However, this is not strictly paired with the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may be called on errors paths before we even call runtime_pm_enable). Make the symmetry more explicit and include a check that we do release all of our rpm wakerefs. v2: Fixup transfer of ownership back to core whilst keeping our wakeref count balanced. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-1-imre.deak@intel.com
-
- 15 8月, 2018 1 次提交
-
-
由 Chris Wilson 提交于
If we pardon a per-engine reset, we may leave the STOP_RING bit asserted in RING_MI_MODE resulting in the engine hanging. Unconditionally clear it on the per-engine exit path as we know that either we skipped the reset and so need the cancellation, or the reset was successful and the cancellation is a no-op, or there was an error and we will follow up with a full-reset or wedging (both of which will stop the engines again as required). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107188 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106560Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180814171857.24673-1-chris@chris-wilson.co.uk
-