- 18 Jun, 2019 4 commits
-
-
Chris Wilson authored
Since commit 1ba62714 ("drm: Add reservation_object to drm_gem_object"), struct drm_gem_object grew its own builtin reservation_object rendering our own private one bloat. Remove our redundant reservation_object and point into obj->base.resv instead. References: 1ba62714 ("drm: Add reservation_object to drm_gem_object") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618125858.7295-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Though we pin the context first before taking the pm wakeref, during retire we need to unpin before dropping the pm wakeref (breaking the "natural" onion). During the unpin, we may need to attach a cleanup operation on to the engine wakeref, ergo we want to keep the engine awake until after the unpin. v2: Push the engine wakeref into the barrier so we keep the onion unwind ordering in the request itself Fixes: ce476c80 ("drm/i915: Keep contexts pinned until after the next kernel context switch") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190618074153.16055-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
If the user is clearing the log buffer too slowly, we overflow. As this is an expected condition, and the driver tries to handle it, reduce the error message down to a notice. Michal mentioned that another cause would be incorrect reset handling, so we don't want to lose the notification entirely. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110817Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617100917.13110-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Fix the plethora of Sphinx build errors after moving the display files under a subdirectory. Fixes: 379bc100 ("drm/i915: move modesetting output/encoder code under display/") Fixes: df0566a6 ("drm/i915: move modesetting core code under display/") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617102944.25129-1-jani.nikula@intel.com
-
- 17 Jun, 2019 25 commits
-
-
Matt Roper authored
Although EHL introduces a new PCH, the South Display part of the PCH that we care about is nearly identical to ICP, just with some pins remapped. Most notably, Port C is mapped to the pins that ICP uses for TC Port 1. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190615004210.16656-1-matthew.d.roper@intel.com
-
Chris Wilson authored
Currently, we perform a locked update of the shadow entry when allocating a page directory entry such that if two clients are concurrently allocating neighbouring ranges we only insert one new entry for the pair of them. However, we also need to serialise both clients wrt to the actual entry in the HW table, or else we may allow one client or even a third client to proceed ahead of the HW write. My handwave before was that under the _pathological_ condition we would see the scratch entry instead of the expected entry, causing a temporary glitch. That starvation condition will eventually show up in practice, so fix it. The reason for the previous cheat was to avoid having to free the extra allocation while under the spinlock. Now, we keep the extra entry allocated until the end instead. v2: Fix error paths for gen6 Fixes: 1d1b5490 ("drm/i915/gtt: Replace struct_mutex serialisation for allocation") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617140426.7203-1-chris@chris-wilson.co.uk
-
Lucas De Marchi authored
In intel_package_header version 2 there's a new field in the fw_info table that must be 0, otherwise it's not the correct DMC firmware. Add a check for version 2 or later. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-10-lucas.demarchi@intel.com
-
Lucas De Marchi authored
parse_csr_fw() is responsible to set up several fields in struct intel_csr, including the payload. We don't need to assign it again. Signed-off-by:
-
Lucas De Marchi authored
Main difference is that now there are up to 20 MMIOs that can be set and a lot of noise due to the struct changing the fields in the middle. Signed-off-by:
-
Lucas De Marchi authored
Complete the extraction of functions to parse specific parts of the firmware. The return of the function parse_csr_fw() is now redundant since it already sets the dmc_payload field. Changing it is left for later to avoid noise in the commit. Signed-off-by:
-
Lucas De Marchi authored
Like parse_csr_fw_css() this parses the package_header from firmware and saves the relevant fields in the csr struct. In this function we also lookup the fw_info we are interested in. Signed-off-by:
-
Lucas De Marchi authored
Let's start splitting the parse function, making all of them return the number of bytes parsed - different versions of the firmware header may require different sizes for the structures. v2: rework remaining bytes calculation on new protection for amount of bytes read Signed-off-by: -
Lucas De Marchi authored
The only meaninful change is that it supports up to 32 fw_info entries rather than the previous max=20. Signed-off-by:
-
Lucas De Marchi authored
Move fw_info out of struct intel_package_header to allow it to grow more easily in future. To make a cleaner move, let's also extract a function to search the header for the dmc_offset. While reviewing this code I wondered why we continued the search even after finding a suitable firmware. Add a comment to explain we will continue to try to find a more specific firmware version, even if this is not required by the spec. Signed-off-by:
-
Lucas De Marchi authored
Change all fields in intel_package_header and intel_dmc_header whose meaning are 1-byte numbers to use u8. Signed-off-by:
-
Mika Kuoppala authored
Allocate all page directory variants with alloc_pd. As the lvl3 and lvl4 variants differ in manipulation, we need to check for existence of backing phys page before accessing it. v2: use err in returns Signed-off-by:
-
Mika Kuoppala authored
All page directories, excluding last level, are initialized with pointer to next level page directories. Make common function for it. Signed-off-by:
-
Mika Kuoppala authored
We set the page directory entries to point into a page table. There is no gen specifics in here so make it simple and obvious. Signed-off-by:
-
Mika Kuoppala authored
All page directories are identical in function, only the position in the hierarchy differ. Use same base type for directory functionality. v2: cleanup, size always 512, init to null Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
We set them to scratch right after allocation so prevent useless zeroing before. v2: atomic_t v3: allow pdp alloc fail Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Greg Kroah-Hartman authored
When calling debugfs functions, there is no need to ever check the return value. The function can work or not, but the code logic should never do something different based on this. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jani Nikula authored
Now that we have a new subdirectory for display code, continue by moving modesetting core code. display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this is, again, a surprisingly clean operation. v2: - don't move intel_sideband.[ch] (Ville) - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Shashank Sharma authored
ICL introduces a new gamma correction mode in display engine, called multi-segmented-gamma mode. This mode allows users to program the darker region of the gamma curve with sueprfine precision. An example use case for this is HDR curves (like PQ ST-2084). If we plot a gamma correction curve from value range between 0.0 to 1.0, ICL's multi-segment has 3 different sections: - superfine segment: 9 values, ranges between 0 - 1/(128 * 256) - fine segment: 257 values, ranges between 0 - 1/(128) - corase segment: 257 values, ranges between 0 - 1 This patch: - Changes gamma LUTs size for ICL/GEN11 to 262144 entries (8 * 128 * 256), so that userspace can program with highest precision supported. - Changes default gamma mode (non-legacy) to multi-segmented-gamma mode. - Adds functions to program/detect multi-segment gamma. V2: Addressed review comments from Ville - separate function for superfine and fine segments. - remove enum for segments. - reuse last entry of the LUT as gc_max value. - replace if() ....cond with switch...case in icl_load_luts. - add an entry variable, instead of 'word' V3: Addressed review comments from Ville - extra newline - s/entry/color/ - remove LUT size checks - program ilk_lut_12p4_ldw value before ilk_lut_12p4_udw - Change the comments in description of fine and coarse segments, and try to make more sense. - use 8 * 128 instead of 1024 - add 1 entry in LUT for GCMAX V4: Addressed review comments from Ville - Remove unused macro - missing shift entry in blue - pick correct entry for GCMAX - Added Ville's R-B Note: Tested and confirmed the programming sequence of odd/even registers in the HW. The correct sequence should be: ilk_lut_12p4_udw ilk_lut_12p4_ldw v5: Addressed Ville's review comments and renamed odd/even register helpers to be more consistent with the values. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Shashank Sharma authored
This patch renames function ivb_load_lut_10_max to ivb_load_lut_ext_max. V3: Added Vill'es r-b. Cc: Uma Shankar <uma.shankar@intel.com> Suggested-by:
-
Uma Shankar authored
Add macros to define multi segmented gamma registers V2: Addressed Ville's comments: Add gen-lable before bit definition Addressed Jani's comment - Use REG_GENMASK() and REG_BIT() V3: Addressed Ville's comments: - Put comments at the end of line. - Change the comment at start of ICL multisegmented gamma registers. Added Ville's r-b Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: -
Shashank Sharma authored
Currently, data type of gamma_lut_size & degamma_lut_size elements in intel_device_info is u16, which means it can accommodate maximum 64k values. In case of ICL multisegmented gamma, the size of gamma LUT is 256K. This patch changes the data type of both of these elements to u32. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> V4: Added Uma's r-b. Reviewed-by:
-
Maarten Lankhorst authored
They have been unused since rotation was added to drm core in 2015, time to get rid of them. Signed-off-by:
-
Jani Nikula authored
Add a new subdirectory for display code, and start off by moving modesetting output/encoder code. Judging by the include changes, this is a surprisingly clean operation. v2: - move intel_sdvo_regs.h too - use tabs for Makefile file lists and sort them Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Ensure intel_sdvo_regs.h is self-contained and remains that way. v2: - include <linux/compiler.h> for __packed (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 15 Jun, 2019 2 commits
-
-
Matt Roper authored
EHL defines two new MOCS table entries but is otherwise compatible with the ICL MOCS table. These table entries (16 and 17) should still be considered unused for ICL and as such their behavior remains undefined for that platform. Signed-off-by:
-
Chris Wilson authored
While we need to flush the wakeref before parking, we do not need to perform the i915_gem_park() itself underneath the wakeref lock, merely the struct_mutex. If we rearrange the locks, we can avoid the unnecessary tainting. Signed-off-by:
-
- 14 Jun, 2019 9 commits
-
-
Chris Wilson authored
To continue the onslaught of removing the assumption of a global execution ordering, another casualty is the engine->timeline. Without an actual timeline to track, it is overkill and we can replace it with a much less grand plain list. We still need a list of requests inflight, for the simple purpose of finding inflight requests (for retiring, resetting, preemption etc). Signed-off-by:
-
Chris Wilson authored
We no longer track the execution order along the engine and so no longer need to enforce ordering of retire along the engine. Signed-off-by:
-
Chris Wilson authored
We need to keep the context image pinned in memory until after the GPU has finished writing into it. Since it continues to write as we signal the final breadcrumb, we need to keep it pinned until the request after it is complete. Currently we know the order in which requests execute on each engine, and so to remove that presumption we need to identify a request/context-switch we know must occur after our completion. Any request queued after the signal must imply a context switch, for simplicity we use a fresh request from the kernel context. The sequence of operations for keeping the context pinned until saved is: - On context activation, we preallocate a node for each physical engine the context may operate on. This is to avoid allocations during unpinning, which may be from inside FS_RECLAIM context (aka the shrinker) - On context deactivation on retirement of the last active request (which is before we know the context has been saved), we add the preallocated node onto a barrier list on each engine - On engine idling, we emit a switch to kernel context. When this switch completes, we know that all previous contexts must have been saved, and so on retiring this request we can finally unpin all the contexts that were marked as deactivated prior to the switch. We can enhance this in future by flushing all the idle contexts on a regular heartbeat pulse of a switch to kernel context, which will also be used to check for hung engines. v2: intel_context_active_acquire/_release Signed-off-by:
-
Daniele Ceraolo Spurio authored
intel_runtime_pm is the only thing they use from the i915 structure, so use that directly. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Matching the underlying get/put functions. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
The functions where internally already only using the structure, so we need to just flip the interface. v2: rebase Signed-off-by:
-
Daniele Ceraolo Spurio authored
Focusing on the functions called in few places. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Asserts aside, all the code working on this structure is in intel_runtime_pm.c and uses the intel_ prefix, so move the structure to intel_runtime_pm.h and adopt the same prefix. Since all the asserts are now working on the runtime_pm structure, bring them across as well. v2: drop unneeded include (Chris), don't rename debugfs, rebase Signed-off-by:
-
Daniele Ceraolo Spurio authored
With this all the rpm assert-related functions consistently work on the i915_runtime_pm structure Signed-off-by:
-
