aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-08-08drm/i915/tgl/dsi: Set latency PCS_DW1 for tglVandita Kulkarni1-2/+2
Latency programming remains same as that of ICL and setting latency otimization for PCS_DW1 lanes is same as that of EHL, hence extending it to TGL. Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730073648.5157-3-vandita.kulkarni@intel.com
2019-08-08drm/i915/tgl/dsi: Program TRANS_VBLANK registerVandita Kulkarni1-0/+9
Program vblank register for mipi dsi in video mode on TGL. Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730073648.5157-2-vandita.kulkarni@intel.com
2019-08-08drm/i915: split out intel_pch.[ch] from i915_drv.[ch]Jani Nikula5-253/+276
Abstract the rather self-contained piece of code from i915_drv.[ch]. No functional changes. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807120415.17917-1-jani.nikula@intel.com
2019-08-07drm/i915/uc: Hardening firmware fetchMichal Wajdeczko2-47/+99
Insert few more failure points into firmware fetch procedure to check use of the wrong blob name or use of the mismatched firmware versions. Also update some messages (remove ptr, duplicated infos) and stop treating all fetch errors as missing firmware case. v2: update log levels (Chris) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [ickle: fixup compiler warning for non-debug builds] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807183759.8588-1-michal.wajdeczko@intel.com
2019-08-07drm/i915/uc: WOPCM programming errors are not always realMichal Wajdeczko1-5/+7
WOPCM programming error might be due to inserted earlier probe failure that could affects HuC firmware loading and thus impacts result of WOPCM partitioning that would be now incompatible with previously programmed values. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-7-michal.wajdeczko@intel.com
2019-08-07drm/i915: Make wopcm_to_i915() privateMichal Wajdeczko2-5/+5
No need to define it globally as we're only using it in wopcm.c Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-6-michal.wajdeczko@intel.com
2019-08-07drm/i915: Don't try to partition WOPCM without GuC firmwareMichal Wajdeczko1-1/+1
For meaningful WOPCM partitioning we need GuC (and optionally HuC) firmware size(s) and we shouldn't just rely on GuC support flag, as we might fail to fetch GuC firmware and it's size will be 0 and all calculations will be just wrong/useless. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-5-michal.wajdeczko@intel.com
2019-08-07drm/i915/uc: Don't fetch HuC fw if GuC fw fetch already failedMichal Wajdeczko3-6/+10
When we failed to fetch GuC firmware there is no point in fetching HuC firmware as we will not be able to use it without working GuC. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-4-michal.wajdeczko@intel.com
2019-08-07drm/i915/uc: HuC firmware can't be supported without GuCMichal Wajdeczko4-10/+21
There is no point in selecting HuC firmware if GuC is unsupported or it was already disabled, as we need GuC to authenticate HuC. While around, make uc_fw_init_early work without direct access to whole i915, pass only needed platform/rev info. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-3-michal.wajdeczko@intel.com
2019-08-07drm/i915/uc: Prefer dev_info for reporting optionsMichal Wajdeczko1-9/+16
While modparams are global for the i915 module, we are reporting status of the params applied against specific device instance. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807170034.8440-2-michal.wajdeczko@intel.com
2019-08-07drm/i915/perf: Refactor oa object to better manage resourcesUmesh Nerlige Ramappa18-589/+596
The oa object manages the oa buffer and must be allocated when the user intends to read performance counter snapshots. This can be achieved by making the oa object part of the stream object which is allocated when a stream is opened by the user. Attributes in the oa object that are gen-specific are moved to the perf object so that they can be initialized on driver load. The split provides a better separation of the objects used in perf implementation of i915 driver so that resources are allocated and initialized only when needed. v2: Fix checkpatch warnings v3: Addressed Lionel's review comment v4: Rebase v5: Fix rebase/merge issue with ratelimit_state_init Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190806233002.984-1-umesh.nerlige.ramappa@intel.com
2019-08-07drm/i915: Isolate i915_getparam_ioctl()Chris Wilson4-167/+172
This giant switch has tendrils all other the struct and does not fit in with the rest of the driver bring up and control in i915_drv.c. Push it to one side so that it can grow in peace. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807142041.32699-1-chris@chris-wilson.co.uk
2019-08-07drm/i915: Include the DRIVER_DATE in the error stateChris Wilson1-0/+1
For forklifted frankenkernels, the reported kernel version has no bearing on the actual driver version. Include our own driver date that is updated every time we tag drm-intel-next. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807113827.28127-1-chris@chris-wilson.co.uk
2019-08-07drm/i915: Fix some NULL vs IS_ERR() conditionsDan Carpenter1-10/+10
There were several places which check for NULL when they should have been checking for IS_ERR(). Fixes: d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190807122832.GA10517@mwanda
2019-08-07drm/i915: Use intel_engine_lookup_user for probing HAS_BSD etcChris Wilson1-4/+8
Use the same mechanism to determine if a backend engine exists for a uabi mapping as used internally. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807083702.16349-2-chris@chris-wilson.co.uk
2019-08-07drm/i915: Rename engines to match their user interfaceChris Wilson4-42/+51
During engine setup, we may find that some engines are fused off causing a misalignment between internal names and the instances seen by users, e.g. (I915_ENGINE_CLASS_VIDEO_DECODE, 1) may be vcs2 in hardware. Normally this is invisible to the user, but a few debug interfaces (and our own internal tracing) use the original HW name not the name the user would expect as formed from their class:instance tuple. Replace our internal name with the uabi name for consistency with, for example, error states. v2: Keep the pretty printing of class name in the selftest Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111311 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807110431.8130-1-chris@chris-wilson.co.uk
2019-08-07drm/i915: Drop expectations of VM_IO from our GGTT mmappingsChris Wilson1-3/+2
We don't really want to use VM_IO for our GGTT mmaps (it implies that the mmap contains memory mapped registers, which we do not expose) yet I overzealously added it to an assert just because that's how we always had setup the vma. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Reviewed-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190807094128.9993-1-chris@chris-wilson.co.uk
2019-08-07drm/i915: abstract display suspend/resume operationsRodrigo Vivi3-71/+84
Increase abstraction of display suspend/resume operations by providing higher level functions, and hiding the details inside intel_display_power.c. v2: Make checkpatch happy: - braces {} are not necessary for single statement blocks v3: Also move hsw/bdw PC8 sequences since they are related to display PM anyways. (Ville) v4: Rebase after a long time, plus Move functions to the new intel_display_power so we can stop exporting platform specific functions as pointed by Jani. v5: Remove unnecessary braces. v6 by Jani: make this purely non-functional cleanup, make functions static Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806122208.16786-2-jani.nikula@intel.com
2019-08-07drm/i915: move property enums to intel_display_types.hJani Nikula2-12/+14
Move the property enums closer to home. Acually make the broadcast macros an enum while at it. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/589d5449a504ec9742dc1fa8d4871d0d6d0cddca.1565085692.git.jani.nikula@intel.com
2019-08-07drm/i915: remove unnecessary includes of intel_display_types.h headerJani Nikula14-24/+7
With its original name intel_drv.h the intel_display_types.h header was superfluously cargo-cult included all over the place, while it's really mostly about display internals. Remove the unnecessary includes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/e3d737f0ab87c55969e62c1e077e15c04c238297.1565085692.git.jani.nikula@intel.com
2019-08-07drm/i915: rename intel_drv.h to display/intel_display_types.hJani Nikula72-77/+86
Everything about the file is about display, and mostly about types related to display. Move under display/ as intel_display_types.h to reflect the facts. There's still plenty to clean up, but start off with moving the file where it logically belongs and naming according to contents. v2: fix the include guard name in the renamed file Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113933.11799-1-jani.nikula@intel.com
2019-08-07drm/i915: avoid including intel_drv.h via i915_drv.h->i915_trace.hJani Nikula19-2/+20
Disentangle i915_drv.h from intel_drv.h, which gets included via i915_trace.h. This necessitates including i915_trace.h wherever it's needed. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ed82bf259d3b725a1a1a3c3e9d6fb5c08bc4d489.1565085691.git.jani.nikula@intel.com
2019-08-07drm/i915/tc: un-inline intel_tc_port_ref_held()Jani Nikula2-7/+9
Avoid including the intel_drv.h mega header from other header files to make further header cleanup easier. v2: restore the over-eagerly dropped <linux/types.h> (Imre) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806113700.18816-1-jani.nikula@intel.com
2019-08-07drm/i915/mst: un-inline intel_dp_mst_encoder_active_links()Jani Nikula2-7/+8
Avoid including the intel_drv.h mega header from other header files to make further header cleanup easier. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ae8f7a9514a9e952e1e0dba411aeb42293d1e183.1565085691.git.jani.nikula@intel.com
2019-08-07drm/i915/bw: make intel_atomic_get_bw_state() staticJani Nikula2-15/+14
No need for this function to be accessible outside of intel_bw.c. Avoid including the i915_drv.h mega header from other header files to make further header cleanup easier. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6c898ec6511af47c1c5b679e516dc757cd207146.1565085691.git.jani.nikula@intel.com
2019-08-07drm/i915/irq: un-inline functions to avoid i915_drv.h includeJani Nikula2-20/+29
Avoid including the i915_drv.h mega header from other header files to make further header cleanup easier. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/45431103f6cbd4322808907154336fdc176ff20d.1565085691.git.jani.nikula@intel.com
2019-08-07drm/i915/sprite: un-inline icl_is_hdr_plane()Jani Nikula2-7/+7
Avoid including the i915_drv.h mega header from other header files to make further header cleanup easier. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5f998c72018c0f1cc5cdb239327a1281d21f4c0e.1565085691.git.jani.nikula@intel.com
2019-08-07drm/i915: move intel_display.c function declarationsJani Nikula3-149/+171
Move the declarations of functions in intel_display.c to intel_display.h. There is still plenty of cleanup to do in intel_display.[ch], but one step at a time. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ebe19d3c508faa82e651ab3c8eb7a0975bfa52b7.1565085691.git.jani.nikula@intel.com
2019-08-06drm/i915/dmc: Load DMC on TGLAnusha Srivatsa1-0/+7
Add Support to load DMC v2.03 on TGL. v2: Use version 2.03 that is already available since that works with PSR2 Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190802183856.27280-1-lucas.demarchi@intel.com
2019-08-06drm/i915/gt: Move the [class][inst] lookup for engines onto the GTChris Wilson21-161/+328
To maintain a fast lookup from a GT centric irq handler, we want the engine lookup tables on the intel_gt. To avoid having multiple copies of the same multi-dimension lookup table, move the generic user engine lookup into an rbtree (for fast and flexible indexing). v2: Split uabi_instance cf uabi_class v3: Set uabi_class/uabi_instance after collating all engines to provide a stable uabi across parallel unordered construction. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> #v2 Link: https://patchwork.freedesktop.org/patch/msgid/20190806124300.24945-2-chris@chris-wilson.co.uk
2019-08-06drm/i915/gem: Make caps.scheduler staticChris Wilson7-28/+22
We do not notify userspace when the scheduler capabilities are changed (due to wedging the driver) and as such userspace will expect the caps to be static and unchanging. Make it so, and so we only need to compute our caps once during driver registration. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806124300.24945-1-chris@chris-wilson.co.uk
2019-08-06drm/i915: Use drm_i915_private directly from drv_get_drvdata()Chris Wilson4-87/+91
As we store a pointer to i915 in the drvdata field (as the pointer is both an alias to the drm_device and drm_i915_private), we can use the stored pointer directly as the i915 device. v2: Store and use i915 inside drv_get_drvdata() v3: Only expect i915 inside drv_get_drvdata() so drop the assumed i915/drm equivalence. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Reviewed-by: Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190806074219.11043-1-chris@chris-wilson.co.uk
2019-08-05drm/i915/gt: Remove stale kerneldoc for internal MOCS functionsChris Wilson1-55/+2
The kerneldoc were stale, generating mismatching parameters warning, but furthermore they were for internal routines, not part of the MOCS interface so the instructions were superfluous. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190803102221.21344-1-chris@chris-wilson.co.uk
2019-08-05drm/i915/uc: Don't fail on HuC early init errorsMichal Wajdeczko2-5/+10
Since commit 301efe96f777 ("drm/i915/uc: Don't fail on HuC firmware failure") we can continue driver load after error during HuC firmware load or authentication, but we could still fail on any error during early HuC initialization. Change that by ignoring HuC related errors until hardware initialization phase where we can decide about next steps. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-5-michal.wajdeczko@intel.com
2019-08-05drm/i915/uc: Remove redundant GuC support checksMichal Wajdeczko1-10/+1
Since commit db81bc6eb9c0 ("drm/i915/uc: Consider enable_guc modparam during fw selection") we have started using firmware status as main indicator of the GuC support. No need to use same checks twice. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-4-michal.wajdeczko@intel.com
2019-08-05drm/i915/huc: Prefer intel_huc_is_supportedMichal Wajdeczko1-1/+1
No need to dance with intel_uc_supports_huc(uc) as we can directly use intel_huc_is_supported(huc) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-3-michal.wajdeczko@intel.com
2019-08-05drm/i915/guc: Prefer intel_guc_is_submission_supportedMichal Wajdeczko1-4/+4
No need to use intel_uc_supports_guc_submission(uc) as we can directly use intel_guc_is_submission_supported(guc) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190804195052.31140-2-michal.wajdeczko@intel.com
2019-08-05drm/i915: Fix wrong escape clock divisor init for GLKStanislav Lisovskiy1-2/+2
According to Bspec clock divisor registers in GeminiLake should be initialized by shifting 1(<<) to amount of correspondent divisor. While i915 was writing all this time that value as is. Surprisingly that it by accident worked, until we met some issues with Microtech Etab. v2: Added Fixes tag and cc v3: Added stable to cc as well. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108826 Fixes: bcc657004841 ("drm/i915/glk: Program txesc clock divider for GLK") Cc: Deepak M <m.deepak@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190712081938.14185-1-stanislav.lisovskiy@intel.com
2019-08-04drm/i915: Replace struct_mutex for batch pool serialisationChris Wilson16-265/+289
Switch to tracking activity via i915_active on individual nodes, only keeping a list of retired objects in the cache, and reaping the cache when the engine itself idles. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-2-chris@chris-wilson.co.uk
2019-08-04drm/i915: Teach execbuffer to take the engine wakeref not GTChris Wilson1-13/+29
In the next patch, we would like to couple into the engine wakeref to free the batch pool on idling. The caveat here is that we therefore want to track the engine wakeref more precisely and to hold it instead of the broader GT wakeref as we process the ioctl. v2: Avoid introducing odd semantics for a shortlived timeline->mutex acquisition interface. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190804124826.30272-1-chris@chris-wilson.co.uk
2019-08-02drm/i915: Flush the freed object list on file closeChris Wilson4-36/+7
As we increase the number of RCU objects, it becomes easier for us to have several hundred thousand objects in the deferred RCU free queues. An example is gem_ctx_create/files which continually creates active contexts, which are not immediately freed upon close as they are kept alive by outstanding requests. This lack of backpressure allows the context objects to persist until they overwhelm and starve the system. We can increase our backpressure by flushing the freed object queue upon closing the device fd which should then not impact other clients. Testcase: igt/gem_ctx_create/*files Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-2-chris@chris-wilson.co.uk
2019-08-02drm/i915: Hide unshrinkable context objects from the shrinkerChris Wilson11-33/+102
The shrinker cannot touch objects used by the contexts (logical state and ring). Currently we mark those as "pin_global" to let the shrinker skip over them, however, if we remove them from the shrinker lists entirely, we don't event have to include them in our shrink accounting. By keeping the unshrinkable objects in our shrinker tracking, we report a large number of objects available to be shrunk, and leave the shrinker deeply unsatisfied when we fail to reclaim those. The shrinker will persist in trying to reclaim the unavailable objects, forcing the system into a livelock (not even hitting the dread oomkiller). v2: Extend unshrinkable protection for perma-pinned scratch and guc allocations (Tvrtko) v3: Notice that we should be pinned when marking unshrinkable and so the link cannot be empty; merge duplicate paths. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190802212137.22207-1-chris@chris-wilson.co.uk
2019-08-02drm/i915/wopcm: Don't fail on WOPCM partitioning failureMichal Wajdeczko4-20/+21
We don't have to immediately fail on WOPCM partitioning, we can wait until we will start programming WOPCM registers. This should give us more options if we decide to restore fallback in case of GuC failures. v3: rebased Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-7-michal.wajdeczko@intel.com
2019-08-02drm/i915/uc: Inject probe errors into intel_uc_init_hwMichal Wajdeczko5-11/+35
Inject probe errors into intel_uc_init_hw to make sure we correctly handle any uC initialization failure. To avoid complains from CI about injected errors use i915_probe_error to lower message level. v4: rebased after moving hot fixes moved to separate patches Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-6-michal.wajdeczko@intel.com
2019-08-02drm/i915/uc: Move GuC error log to uc and release it on finiMichal Wajdeczko4-18/+16
When we fail to load GuC and want to abort probe, we hit: <7> [229.915779] i915 0000:00:02.0: [drm:intel_uc_init_hw [i915]] GuC initialization failed -6 <7> [229.915813] i915 0000:00:02.0: [drm:i915_gem_init_hw [i915]] Enabling uc failed (-6) <4> [229.953354] ------------[ cut here ]------------ <4> [229.953355] WARN_ON(dev_priv->mm.shrink_count) <4> [229.953406] WARNING: CPU: 9 PID: 3287 at drivers/gpu/drm/i915/i915_gem.c:1684 i915_gem_cleanup_early+0xfc/0x110 [i915] <4> [229.953464] Call Trace: <4> [229.953489] i915_driver_late_release+0x19/0x60 [i915] <4> [229.953514] i915_driver_probe+0xb82/0x18a0 [i915] <4> [229.953519] ? __pm_runtime_resume+0x4f/0x80 <4> [229.953545] i915_pci_probe+0x43/0x1b0 [i915] ... <4> [229.962951] ------------[ cut here ]------------ <4> [229.962956] DEBUG_LOCKS_WARN_ON(lock->magic != lock) <4> [229.962959] WARNING: CPU: 8 PID: 2395 at kernel/locking/mutex.c:912 __mutex_lock+0x750/0x9b0 <4> [229.963091] Call Trace: <4> [229.963129] ? i915_vma_destroy+0x86/0x350 [i915] <4> [229.963166] ? i915_vma_destroy+0x86/0x350 [i915] <4> [229.963201] i915_vma_destroy+0x86/0x350 [i915] <4> [229.963236] __i915_gem_free_objects+0xb8/0x510 [i915] <4> [229.963270] __i915_gem_free_work+0x5a/0x90 [i915] <4> [229.963275] process_one_work+0x245/0x610 as since commit 6f76098fe0f3 ("drm/i915/uc: Move uC early functions inside the GT ones") we cleanup uc after gem. Move captured GuC load error log to uc struct and release it in intel_uc_fini() instead of intel_uc_driver_late_release() Note that intel_uc_driver_late_release() is now empty, but we can leave it as a placeholder for future code. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-5-michal.wajdeczko@intel.com
2019-08-02drm/i915/uc: Reorder firmware status codesMichal Wajdeczko1-7/+7
On Gen9 when we try to reload HuC due to GuC upload error, we hit: <7> [232.025927] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s) <7> [232.026004] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin <7> [232.026686] [drm:intel_uc_fw_upload [i915]] HuC fw xfer completed <6> [232.026688] [drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0) <3> [232.026703] intel_uc_fw_copy_rsa:541 GEM_BUG_ON(!intel_uc_fw_is_available(uc_fw)) as firmware that previously failed to load was wrongly treated as unavailable since its status code was not matching status check logic. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-4-michal.wajdeczko@intel.com
2019-08-02drm/i915/uc: Do full sanitize instead of pure resetMichal Wajdeczko1-3/+3
On Gen9 when we try to reload HuC due to GuC upload error, we hit: <7> [229.656688] [drm:intel_uc_init_hw [i915]] GuC fw load failed: -8; will reset and retry 2 more time(s) <7> [229.656739] [drm:intel_uc_fw_upload [i915]] HuC fw load i915/kbl_huc_ver02_00_1810.bin <3> [229.656740] intel_uc_fw_upload:425 GEM_BUG_ON(intel_uc_fw_is_loaded(uc_fw)) as we performed only pure reset and didn't sanitized HuC fw status. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-3-michal.wajdeczko@intel.com
2019-08-02drm/i915: Add i915 to i915_inject_probe_failureMichal Wajdeczko9-30/+31
With i915 added to i915_inject_probe_failure we can use dedicated printk when injecting artificial load failure. Also make this function look like other i915 functions that return error code and make it more flexible to return any provided error code instead of previously assumed -ENODEV. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802184055.31988-2-michal.wajdeczko@intel.com
2019-08-02drm/i915: Report resv_obj allocation failureChris Wilson1-22/+9
Since commit 64d6c500a384 ("drm/i915: Generalise GPU activity tracking"), we have been prepared for i915_vma_move_to_active() to fail. We can take advantage of this to report the failure for allocating the shared-fence slot in the reservation_object. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190730205805.3733-1-chris@chris-wilson.co.uk
2019-08-02drm/i915: Fix documentation for __intel_wait_for_register_fw*Michal Wajdeczko1-2/+2
Use section name "Return" and proper error code -ETIMEDOUT Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190802124739.12548-1-michal.wajdeczko@intel.com
Powered by cgit, Gruvboxed by Blaster4385.