summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)Author
2018-09-13drm/i915/skl+: don't trust IPC value set by BIOSMahesh Kumar
If KMS decide to disable IPC make sure we override IPC configuration set by BIOS. Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-5-mahesh1.kumar@intel.com
2018-09-13drm/i915: Implement 16GB dimm wa for latency level-0Mahesh 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: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180831110942.9234-1-mahesh1.kumar@intel.com
2018-09-13drm/i915/skl+: Decode memory bandwidth and parametersMahesh 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: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-3-mahesh1.kumar@intel.com
2018-09-13drm/i915/bxt: Decode memory bandwidth and parametersMahesh 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: Mahesh Kumar <mahesh1.kumar@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180824093225.12598-2-mahesh1.kumar@intel.com
2018-09-13firmware/dmc/icl: load v1.07 on icelake.Anusha Srivatsa
Add Support to load DMC on Icelake. While at it, also add support to load the firmware during system resume. v2: load firmware during system resume.(Imre) v3: enable has_csr for icelake.(Jyoti) v4: Only load the firmware in this patch Cc: Jyoti Yadav <jyoti.r.yadav@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180828003844.4682-2-anusha.srivatsa@intel.com
2018-09-13drm/i915: Fix a potential integer overflow with framebuffers extending past ↵Ville Syrjälä
4 GiB If we have framebuffers that are >= 4GiB in size we will overflow the fb size check in intel_fill_fb_info(). Currently that is only possible with NV12 and CCS as offsets[1] may be anything between 0 and 0xffffffff. offsets[0] is currently required to be 0 so we can't hit the overflow with any single plane format (thanks to max fb size of 8kx8k and max stride of 32 KiB). In the future we may allow almost any framebuffer to exceed 4GiB in size so we really should fix the overflow. Not that the overflow is particularly dangerous. It's mostly just a sanity check against insane userspace. The display engine can't write to memory anyway so I suppose in the worst case we might anger the hw by attempting scanout past the end of the ggtt, or we might scan out some data that we're not supposed to see from other parts of the ggtt. Note that triggering this overflow depends on the driver aligning the fb height to the next tile boundary to push the calculated size above 4GiB. With linear buffers the effective tile height is one so that never happens, and the core already has a check for 32bit overflow of offsets[]+pitches[]*height. v2: Drop the unnecessary cast (Chris) Testcase: igt/kms_big_fb/x-tiled-addfb-size-offset-overflow Testcase: igt/kms_big_fb/y-tiled-addfb-size-offset-overflow Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180912180443.28649-1-ville.syrjala@linux.intel.com
2018-09-13drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZEVille Syrjälä
Use I915_GTT_PAGE_SIZE when talking about GTT pages rather than physical pages. There are some PAGE_SHIFTs left though. Not sure if we want to introduce I915_GTT_PAGE_SHIFT or what? Cc: Chris Wilson <chris@chris-wilson.co.uk> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> # at least some of it :) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180913150405.706-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-09-13i915/oa: Simplify updating contextsTvrtko Ursulin
We can remove the update-via-batch-buffer code path, which is basically an effective duplicate of update-via-context-image path, if we notice that after we have idled the GPU, we can update the context image even of the kernel context directly. (Update-via-batch-buffer path existed only to solve the problem of how to update the kernel context image.) Only additional thing needed is to activate the edited configuration by sending one empty request down the pipe. This accomplishes context restore of the updated kernel context and so the OA configuration gets written out to it's control registers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180912152930.28237-1-tvrtko.ursulin@linux.intel.com
2018-09-12drm/i915: Extract intel_cursor_check_surface()Ville Syrjälä
Extract intel_cursor_check_surface() to better match the code layout of the other plane types. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-14-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Move chv rotation checks to plane->check()Ville Syrjälä
Move the chv rotation vs. reflections checks to the plane->check() hook, away from the (now) platform agnostic intel_plane_atomic_check_with_state(). Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-13-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Move display w/a #1175Ville Syrjälä
Move the display w/a #1175 to a better place. That place being the new skl+ specific plane->check() hook. This leaves the skl_check_plane_surface() stuff to deal with the gtt offset and src coordinate stuff as originally envisioned. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-12-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Move skl plane fb related checks into a better placeVille Syrjälä
Move the skl+ specific framebuffer related checks from intel_plane_atomic_check_with_state() into a new function (skl_plane_check_fb()) which we'll simply call from the skl plane->check() hook. v2: Split out the Y/Yf+CCS vs. interlaced change (José) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-11-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Extract per-platform plane->check() functionsVille Syrjälä
Split up intel_check_primary_plane() and intel_check_sprite_plane() into per-platform variants. This way we can get a unified behaviour between the SKL universal planes, and we stop checking for non-SKL specific scaling limits for the "sprite" planes. And we now get a natural place where to add more plarform specific checks. v2: Split the .check_plane() calling convention change out (José) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-10-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Nuke plane->can_scale/min_downscaleVille Syrjälä
We can easily calculate the plane can_scale/min_downscale on demand. And later on we'll probably want to start calculating these dynamically based on the cdclk just as skl already does. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-9-ville.syrjala@linux.intel.com
2018-09-12drm/i915: s/int plane/int color_plane/Ville Syrjälä
To reduce the confusion between a drm plane and the planes of framebuffers let's desiginate the latter as "color plane". Weak-Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-8-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Store ggtt_view in plane_stateVille Syrjälä
Stash the gtt_view structure into the plane state. This will become useful when we do GTT remapping as the gtt_view will not come directly from the fb anymore. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-7-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Store the final plane stride in plane_stateVille Syrjälä
Let's store the final plane stride in the plane state. This avoids having to pick between the normal vs. rotated stride during hardware programming. And once we get GTT remapping the plane stride will no longer match the fb stride so we'll need a place to store it anyway. v2: Keep checking fb->pitches[0] for cursor as later on we won't populate plane_state->color_plane[0].stride for invisible planes and we have been checking the cursor fb stride even for invisible planes v3: s/betwen/between in commit msg (José) v4: Check color_plane[0].stride instead of fb->pitches[0] in the skl_check_main_surface() X-tiling kludge Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180911150139.23922-1-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Rename the plane_state->main/aux to plane_state->color_plane[]Ville Syrjälä
Make the main/aux surface stuff a bit more generic by using an array of structures. This will allow us to deal with both the main and aux surfaces with common code. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-5-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Use pipe A primary plane .max_stride() as the global stride limitVille Syrjälä
Let's assume that the primary plane for pipe A has the highest max stride of all planes, and we'll use that as the global limit when creating a new framebuffer. Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-4-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Add .max_stride() plane hookVille Syrjälä
Each plane may have different stride limitations. Let's add a new plane function to retutn the maximum stride for each plane. There's going to be some use for this outside the .atomic_check() stuff hence the separate hook. v2: Fix ilk+ x-tiled max stride to be 32k (José) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-3-ville.syrjala@linux.intel.com
2018-09-12drm/i915: s/tile_offset/aligned_offset/ etc.Ville Syrjälä
Rename some of the tile_offset() functions to aligned_offset() since they operate on both linear and tiled functions. And we'll include _plane_ in the name of all the variants that take a plane state. Should make it more clear which function to use where. v2: Pimp the patch subject a bit (José) Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907152413.15761-2-ville.syrjala@linux.intel.com
2018-09-12drm/i915: Reorder execobject[] to insert non-48b objects into the low 4GChris Wilson
If the caller supplies more than 4G of objects and than one that has to be in the low 4G, it is possible for the low 4G to be full before we attempt to find room for the last object that must be there. As we don't reorder the two types, every pass hits the same problem and we fail with ENOSPC. However, if we impose a little bit of ordering between the two classes of objects, on the second pass we will be able to fit the special object as we do it first. For setups that only use !48b objects, we now reverse the order between passes, hopefully making the subsequent passes more likely to succeed given that we are trying a different order (rather than repeating the previous pass!) v2: Quick one line explanation for the relative priorities given to reservations. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180912101133.31377-1-chris@chris-wilson.co.uk
2018-09-12drm/i915/ringbuffer: Reload PDs harder on byt/bcsChris Wilson
Baytrail takes a little more convincing that it needs to actually reload its Page Directoy (ppGTT) before the context switch, so repeat it until it gets the message. Once again the arbitrary values here are empirically derived. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107861 Testcase: igt/gem_exec_parallel/fds Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180910130808.10809-1-chris@chris-wilson.co.uk
2018-09-11drm/i915: Nuke struct_mutex from context_setparamChris Wilson
Userspace should be free to race against itself and shoot itself in the foot if it so desires to adjust a parameter at the same time as submitting a batch to that context. As such, the struct_mutex in context setparam is only being used to serialise userspace against itself and not for any protection of internal structs and so is superfluous. v2: Separate user_flags from internal flags to reduce chance of interference; and use locked bit ops for user updates. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180911132206.23032-1-chris@chris-wilson.co.uk
2018-09-11drm/i915/icl: Define T_INIT_MASTER registersMadhav Chauhan
This patch defines DSI_T_INIT_MASTER register for DSI ports 0/1 which will be used in dphy programming. Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531215614-6828-5-git-send-email-madhav.chauhan@intel.com
2018-09-11drm/i915/overlay: Use the ioctl parameters directlyChris Wilson
The user parameters to put_image are not copied back to userspace (DRM_IOW), and so we can modify the ioctl parameters (having already been copied to a temporary kernel struct) directly and use those in place, avoiding another temporary malloc and lots of manual copying. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180906190144.1272-2-chris@chris-wilson.co.uk
2018-09-11drm/i915/overlay: Allocate physical registers from stolenChris Wilson
Given that we are now reasonably confident in our ability to detect and reserve the stolen memory (physical memory reserved for graphics by the BIOS) for ourselves on most machines, we can put it to use. In this case, we need a page to hold the overlay registers. On an i915g running MythTv, H Buus noticed that commit 6a2c4232ece145d8b5a8f95f767bd6d0d2d2f2bb Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Nov 4 04:51:40 2014 -0800 drm/i915: Make the physical object coherent with GTT introduced stuttering into his video playback. After discarding the likely suspect of it being the physical cursor updates, we were left with the use of the phys object for the overlay. And lo, if we completely avoid using the phys object (allocated just once on module load!) by switching to stolen memory, the stuttering goes away. For lack of a better explanation, claim victory and kill two birds with one stone. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107600 Fixes: 6a2c4232ece1 ("drm/i915: Make the physical object coherent with GTT") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180906190144.1272-1-chris@chris-wilson.co.uk
2018-09-11drm/i915/chv: Update csc coefficient matrix during modesetP Raviraj Sitaram
During modeset, previously configured csc coefficient matrix,if any, will not persist. This can result in blank screen as csc mode will be programmed while loading LUT but csc coefficient matrix remains unprogrammed. Changes since V1: - Removed platform check Signed-off-by: P Raviraj Sitaram <raviraj.p.sitaram@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1536589634-29680-1-git-send-email-raviraj.p.sitaram@intel.com
2018-09-10drm/i915/guc: Update GuC power domain statesMichal Wajdeczko
We should update GuC power domain states also when GuC submission is disabled, otherwise GuC might complain or ignore our requests. This seems to be required for all currently released GuC firmwares. v2: it is only needed by pre-Gen11 firmwares Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: John Spotswood <john.a.spotswood@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20180910104150.101752-1-michal.wajdeczko@intel.com
2018-09-07drm/i915: Missed interrupt simulation is no more, tell the worldChris Wilson
Using the guc, we cannot disable the user interrupt generation as we use it for driving submission. And from Icelake, we no longer have the ability to individually mask interrupt generation from each engine, disabling our ability to fake missed interrupts. In both cases, report back to userspace that the missed interrupt generator is no longer available. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180907112856.28242-1-chris@chris-wilson.co.uk
2018-09-06drm/i915: Update DRIVER_DATE to 20180906Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-06Merge tag 'gvt-next-2018-09-04' of https://github.com/intel/gvt-linux into ↵Joonas Lahtinen
drm-intel-next-queued gvt-next-2018-09-04 - guest context shadow optimization for restore inhibit one (Yan) - cmd parser optimization (Yan) - W=1 warning fixes (Zhenyu) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> # Conflicts: # drivers/gpu/drm/i915/gvt/reg.h From: Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904030154.GG20737@zhen-hp.sh.intel.com
2018-09-06drm/i915: Update DRIVER_DATE to 20180906Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-06drm/i915: Update DRIVER_DATE to 20180906Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-05drm/i915: Move final cleanup of drm_i915_private to i915_driver_destroyChris Wilson
Introduce a complementary function to i915_driver_create() to undo all that is created. Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905140921.17467-2-chris@chris-wilson.co.uk
2018-09-05drm/i915: Attach the pci match data to the device upon creationChris Wilson
Attach our device_info to the our i915 private on creation so that it is always available for inspection. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905140921.17467-1-chris@chris-wilson.co.uk
2018-09-05drm/i915/bdw: Increase IPS disable timeout to 100msImre Deak
During IPS disabling the current 42ms timeout value leads to occasional timeouts, increase it to 100ms which seems to get rid of the problem. References: https://bugs.freedesktop.org/show_bug.cgi?id=107494 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107562 Reported-by: Diego Viola <diego.viola@gmail.com> Tested-by: Diego Viola <diego.viola@gmail.com> Cc: Diego Viola <diego.viola@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180905100005.7663-1-imre.deak@intel.com
2018-09-05drm/i915: Reduce context HW ID lifetimeChris Wilson
Future gen reduce the number of bits we will have available to differentiate between contexts, so reduce the lifetime of the ID assignment from that of the context to its current active cycle (i.e. only while it is pinned for use by the HW, will it have a constant ID). This means that instead of a max of 2k allocated contexts (worst case before fun with bit twiddling), we instead have a limit of 2k in flight contexts (minus a few that have been pinned by the kernel or by perf). To reduce the number of contexts id we require, we allocate a context id on first and mark it as pinned for as long as the GEM context itself is, that is we keep it pinned it while active on each engine. If we exhaust our context id space, then we try to reclaim an id from an idle context. In the extreme case where all context ids are pinned by active contexts, we force the system to idle in order to recover ids. We cannot reduce the scope of an HW-ID to an engine (allowing the same gem_context to have different ids on each engine) as in the future we will need to preassign an id before we know which engine the context is being executed on. v2: Improved commentary (Tvrtko) [I tried at least] References: https://bugs.freedesktop.org/show_bug.cgi?id=107788 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904153117.3907-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Be defensive and don't assume PSR has any commit to sync againstChris Wilson
If the previous modeset commit has completed and is no longer part of the crtc state, skip waiting for it. Ville pointed out that, in fact, the commit is never removed after a modeset so the only way we could see a NULL here should be if there was never a commit attached. Nevertheless, we have the evidence it can be NULL and it has been defended against elsewhere, for example commit 93313538c153 ("drm/i915: Pass idle crtc_state to intel_dp_sink_crc"). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107792 Fixes: c44301fce614 ("drm/i915: Allow control of PSR at runtime through debugfs, v6") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904162902.2578-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Pull intel_uncore_arm_unclaimed_mmio_detection() under the spinlockChris Wilson
Elsewhere we manipulate uncore.unclaimed_mmio_check and i915_param.mmio_debug under the irq lock (e.g. preserving the current value across a user forcewake grab), but do not protect the manipulation inside intel_uncore_arm_unclaimed_mmio_detection() from concurrent access, even from itself. This is an issue as we do call arm_unclaimed_mmio_detection from multiple threads without coordination. Suggested-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intelcom> Link: https://patchwork.freedesktop.org/patch/msgid/20180904131207.17563-1-chris@chris-wilson.co.uk
2018-09-04drm/i915/icl: Fix context RPCS programmingTvrtko Ursulin
There are two issues with the current RPCS programming for Icelake: Expansion of the slice count bitfield has been missed, as well as the required programming workaround for the subslice count bitfield size limitation. 1) Bitfield width for configuring the active slice count has grown so we need to program the GEN8_R_PWR_CLK_STATE accordingly. Current code was always requesting eight times the number of slices (due writing to a bitfield starting three bits higher than it should). These requests were luckily a) capped by the hardware to the available number of slices, and b) we haven't yet exported the code to ask for reduced slice configurations. Due both of the above there was no impact from this incorrect programming but we should still fix it. 2) Due subslice count bitfield being only three bits wide and furthermore capped to a maximum documented value of four, special programming workaround is needed to enable more than four subslices. With this programming driver has to consider the GT configuration as 2x4x8, while the hardware internally translates this to 1x8x8. A limitation stemming from this is that either a subslice count between one and four can be selected, or a subslice count equaling the total number of subslices in all selected slices. In other words, odd subslice counts greater than four are impossible, as are odd subslice counts greater than a single slice subslice count. This also had no impact in the current code base due breakage from 1) always reqesting more than one slice. While fixing this we also add some asserts to flag up any future bitfield overflows. v2: * Use a local in all branches for clarity. (Lionel) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Bspec: 12247 Reported-by: tony.ye@intel.com Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: tony.ye@intel.com Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903113007.2643-1-tvrtko.ursulin@linux.intel.com
2018-09-04drm/i915/ringbuffer: Move double invalidate to after pd flushChris Wilson
Continuing the fun of trying to find exactly the delay that is sufficient to ensure that the page directory is fully loaded between context switches, move the extra flush added in commit 70b73f9ac113 ("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs") to just after we flush the pd. Entirely based on the empirical data of running failing tests in a loop until we survive a day (before the mtbf is 10-30 minutes). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107769 References: 70b73f9ac113 ("drm/i915/ringbuffer: Delay after invalidating gen6+ xcs") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904063802.13880-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Double check we didn't miss an unclaimed register accessChris Wilson
Currently, if the user has enabled mmio-debug around each register access, we presume that we have then checked them all. However, it is still possible through omission (raw register access) or external interaction that the unclaimed access was not highlighted. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180904111732.24266-1-chris@chris-wilson.co.uk
2018-09-04drm/i915: Fix ICL+ HDMI clock readoutVille Syrjälä
Copy the 38.4 vs. 19.2 MHz ref clock exception from the dpll mgr into the clock readout function as well. v2: Refactor the code into a common function s/is_icl/gen11+/ (Rodrigo) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107722 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903142841.14627-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-09-03drm/i915: Use a cached mapping for the physical HWSChris Wilson
Older gen use a physical address for the hardware status page, for which we use cache-coherent writes. As the writes are into the cpu cache, we use a normal WB mapped page to read the HWS, used for our seqno tracking. Anecdotally, I observed lost breadcrumbs writes into the HWS on i965gm, which so far have not reoccurred with this patch. How reliable that evidence is remains to be seen. v2: Explicitly pass the expected physical address to the hw v3: Also remember the wild writes we once had for HWS above 4G. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180903152304.31589-2-chris@chris-wilson.co.uk
2018-09-03drm/i915: Combine cleanup_status_page()Chris Wilson
Pull the physical status page cleanup into a common cleanup_status_page() for caller simplicity. 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/20180903152304.31589-1-chris@chris-wilson.co.uk
2018-09-03drm/i915: Fix up FORCE_GPU_RELOC (debug) to flush CPU write domainsChris Wilson
We currently assert that if the target is in a CPU write domain, we use a CPU reloc path rather than the GPU reloc path. However, we have a debug override to force the GPU path and that unfortunately hits the assert. Include the async clflush under the debug option to ensure correct behaviour even when debugging, and strict when not. 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/20180903150216.19965-1-chris@chris-wilson.co.uk
2018-09-03drm/i915: Update DRIVER_DATE to 20180903Joonas Lahtinen
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-09-03drm/i915: Forcibly flush unwanted requests in drop-cachesChris Wilson
Add a mode to debugfs/drop-caches to flush unwanted requests off the GPU (by wedging the device and resetting). This is very useful if a test terminated leaving a long queue of hanging batches that would ordinarily require a round trip through hangcheck for each. It reduces the inter-test operation to just a write into drop-caches to reset driver/GPU state between tests. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-5-chris@chris-wilson.co.uk
2018-09-03drm/i915: Early rejection of buffer allocations larger than RAMChris Wilson
We currently try to pin and allocate the whole buffer at a time. If that object is larger than RAM, we will try to pin the whole of physical memory, force the machine into oom, and then still fail the allocation. If the request is obviously too large, error out early. We opt to do this in the backend to make it easy to use alternate paths that do not require the entire object pinned, or may easily handle proxy objects that are larger than physical memory. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180903083337.13134-4-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.46.0) at 2026-05-05 09:49:46 +0000