- 10 Feb, 2020 2 commits
-
-
Jani Nikula authored
Make future work slightly easier. Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204135217.21974-1-jani.nikula@intel.com
-
Jani Nikula authored
Commit 21fd23ac ("drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms") pushed pipe and vblank enable to encoders on DDI platforms, however it missed the DP MST encoder. Fix it. Fixes: 21fd23ac ("drm/i915: move pipe, pch and vblank enable to encoders on DDI platforms") Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reported-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
-
- 09 Feb, 2020 3 commits
-
-
Chris Wilson authored
On an allocation error path for live_hwsp_alternate, we dropped the engine wakeref before we had even acquired it. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Chris Wilson authored
Recording the frequent inspection of CSB head/tail when there is expected to be no update adds noise to the debug trace. (Not entirely useless, but since we know the sequence of function calls, we can surmise the function was called -- so redundant.) Signed-off-by:
-
Chris Wilson authored
In eliminating the recursion from walking the tree of signalers/waiters for processing the hold/unhold operations, a crucial error crept in where we looked at the parent request and not the list element when processing the list. Brown paper bag, much? Closes: https://gitlab.freedesktop.org/drm/intel/issues/1166 Fixes: 32ff621f ("drm/i915/gt: Allow temporary suspension of inflight requests") Fixes: 74831738 ("drm/i915/execlists: Offline error capture") Signed-off-by:
-
- 08 Feb, 2020 4 commits
-
-
Mika Kuoppala authored
We have switched from tail manipulation to forced context restore to implement WaIdleLiteRestore. Remove the old defines and comments. Note: we still do emit the WA tail, and use it as our first attempt to avoid forcing a full-restore instead of a lite-restore, we just have a much stronger backup mechanism for repeated preemptions. References: f26a9e95 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Janusz Krzysztofik authored
Commit 4f2a572e ("drm/i915/userptr: Never allow userptr into the mappable GGTT") made I915_GEM_MMAP_GTT IOCTLs to fail when attempted on a userptr object in order to protect from a lockdep splat. Later on, new mapping types were introduced by commit cc662126 ("drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET"). Those new mapping types suffer from the same lockdep splat issue but they now succeed when tried on top of a userptr object. Fix it. v2: Don't play with the -ENODEV driver response (Chris) Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Tvrtko Ursulin authored
Last IGT user (intel_gpu_overlay) stopped using it in October 2019 so we are good to remove the file. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
Moving the base forward since this one was so old. New base contains fixes that we needed. Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 07 Feb, 2020 15 commits
-
-
Chris Wilson authored
If we rewind the RING_TAIL on a context, due to a preemption event, we must force the context restore for the RING_TAIL update to be properly handled. Rather than note which preemption events may cause us to rewind the tail, compare the new request's tail with the previously submitted RING_TAIL, as it turns out that timeslicing was causing unexpected rewinds. <idle>-0 0d.s2 1280851190us : __execlists_submission_tasklet: 0000:00:02.0 rcs0: expired last=130:4698, prio=3, hint=3 <idle>-0 0d.s2 1280851192us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 66:119966, current 119964 <idle>-0 0d.s2 1280851195us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4698, current 4695 <idle>-0 0d.s2 1280851198us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 130:4696, current 4695 ^---- Note we unwind 2 requests from the same context <idle>-0 0d.s2 1280851208us : __i915_request_submit: 0000:00:02.0 rcs0: fence 130:4696, current 4695 <idle>-0 0d.s2 1280851213us : __i915_request_submit: 0000:00:02.0 rcs0: fence 134:1508, current 1506 ^---- But to apply the new timeslice, we have to replay the first request before the new client can start -- the unexpected RING_TAIL rewind <idle>-0 0d.s2 1280851219us : trace_ports: 0000:00:02.0 rcs0: submit { 130:4696*, 134:1508 } synmark2-5425 2..s. 1280851239us : process_csb: 0000:00:02.0 rcs0: cs-irq head=5, tail=0 synmark2-5425 2..s. 1280851240us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x00008002:0x00000000 ^---- Preemption event for the ELSP update; note the lite-restore synmark2-5425 2..s. 1280851243us : trace_ports: 0000:00:02.0 rcs0: preempted { 130:4698, 66:119966 } synmark2-5425 2..s. 1280851246us : trace_ports: 0000:00:02.0 rcs0: promote { 130:4696*, 134:1508 } synmark2-5425 2.... 1280851462us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4700, current 4695 synmark2-5425 2.... 1280852111us : __i915_request_commit: 0000:00:02.0 rcs0: fence 130:4702, current 4695 synmark2-5425 2.Ns1 1280852296us : process_csb: 0000:00:02.0 rcs0: cs-irq head=0, tail=2 synmark2-5425 2.Ns1 1280852297us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x00000814:0x00000000 synmark2-5425 2.Ns1 1280852299us : trace_ports: 0000:00:02.0 rcs0: completed { 130:4696!, 134:1508 } synmark2-5425 2.Ns1 1280852301us : process_csb: 0000:00:02.0 rcs0: csb[2]: status=0x00000818:0x00000040 synmark2-5425 2.Ns1 1280852302us : trace_ports: 0000:00:02.0 rcs0: completed { 134:1508, 0:0 } synmark2-5425 2.Ns1 1280852313us : process_csb: process_csb:2336 GEM_BUG_ON(!i915_request_completed(*execlists->active) && !reset_in_progress(execlists)) Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Referenecs: 82c69bf5 ("drm/i915/gt: Detect if we miss WaIdleLiteRestore") Signed-off-by: -
Chris Wilson authored
If a request is being re-run after an innocent reset, it is marked as -EAGAIN. So only skip an engine reset if the request is marked as -EIO. Testcase: igt/gem_ctx_exec/basic-nohangcheck Signed-off-by:
-
Mika Kuoppala authored
SIMD16 with Src0 scalar might conflict between Src1/Src2 and cause GRF read issue. Workaround this issue by setting bit 14 in 0xe4f4 which will disable early read/src swap of Src0. Signed-off-by:
-
Mika Kuoppala authored
Disable TEDOP clock gating flow by programming 0x20A0[19] = 1 References: HSDES#1407928979 Signed-off-by:
-
Chris Wilson authored
We set up a dummy ring in order to measure the size we require for our breadcrumb emission, so that we don't have to manually count dwords! We can pass in the kernel_context to use for this so that if required it is known for the breadcrumb emitter, and we can reuse some details from the kernel_context to reduce the number of temporaries we have to mock. Signed-off-by:
-
Chris Wilson authored
Do not try and dereference the i915 private before it has been allocated and attached to the drvdata! Fixes: 7daac72e ("drm/i915/pci: conversion to drm_device based logging macros.") Signed-off-by:
-
Michal Wajdeczko authored
We are sanitizing firmware status and old mmio message, but we forget to sanitize CT status. Fixes: e85de177 ("drm/i915/guc: Introduce guc_is_ready") Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Chris Wilson authored
As we may add new waiters to a request as it is being run, we need to mark the list iteration as being safe for concurrent addition. v2: Mika spotted that we used the same trick for signalers_list, so warn the compiler about the lockless walk there as well. Fixes: 32ff621f ("drm/i915/gt: Allow temporary suspension of inflight requests") Signed-off-by:
-
Lyude Paul authored
This reverts commit d2a4bb6f. So, turns out that this ended up just breaking things. While many laptops incorrectly advertise themselves as supporting PWM backlight controls, they actually will only work with DPCD backlight controls. Unfortunately, it also seems there are a number of systems which advertise DPCD backlight controls in their eDP DPCD but don't actually support them. Talking with some laptop manufacturers has shown it might be possible to probe this support via the EDID (!?!?) but I haven't been able to confirm that this would work on any other manufacturer's systems. So in the mean time, we'll just revert this commit for now and go back to the old way of doing things. Fixes: d2a4bb6f ("drm/i915: Don't use VBT for detecting DPCD backlight controls") Signed-off-by:
Lyude Paul <lyude@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
Mika spotted <4>[17436.705441] general protection fault: 0000 [#1] PREEMPT SMP PTI <4>[17436.705447] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.5.0+ #1 <4>[17436.705449] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3805 05/16/2018 <4>[17436.705512] RIP: 0010:__execlists_submission_tasklet+0xc4d/0x16e0 [i915] <4>[17436.705516] Code: c5 4c 8d 60 e0 75 17 e9 8c 07 00 00 49 8b 44 24 20 49 39 c5 4c 8d 60 e0 0f 84 7a 07 00 00 49 8b 5c 24 08 49 8b 87 80 00 00 00 <48> 39 83 d8 fe ff ff 75 d9 48 8b 83 88 fe ff ff a8 01 0f 84 b6 05 <4>[17436.705518] RSP: 0018:ffffc9000012ce80 EFLAGS: 00010083 <4>[17436.705521] RAX: ffff88822ae42000 RBX: 5a5a5a5a5a5a5a5a RCX: dead000000000122 <4>[17436.705523] RDX: ffff88822ae42588 RSI: ffff8881e32a7908 RDI: ffff8881c429fd48 <4>[17436.705525] RBP: ffffc9000012cf00 R08: ffff88822ae42588 R09: 00000000fffffffe <4>[17436.705527] R10: ffff8881c429fb80 R11: 00000000a677cf08 R12: ffff8881c42a0aa8 <4>[17436.705529] R13: ffff8881c429fd38 R14: ffff88822ae42588 R15: ffff8881c429fb80 <4>[17436.705532] FS: 0000000000000000(0000) GS:ffff88822ed00000(0000) knlGS:0000000000000000 <4>[17436.705534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4>[17436.705536] CR2: 00007f858c76d000 CR3: 0000000005610003 CR4: 00000000003606e0 <4>[17436.705538] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4>[17436.705540] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 <4>[17436.705542] Call Trace: <4>[17436.705545] <IRQ> <4>[17436.705603] execlists_submission_tasklet+0xc0/0x130 [i915] which is us consuming a partially initialised new waiter in defer_requests(). We can prevent this by initialising the i915_dependency prior to making it visible, and since we are using a concurrent list_add/iterator mark them up to the compiler. Fixes: 8ee36e04 ("drm/i915/execlists: Minimalistic timeslicing") Signed-off-by:
-
Chris Wilson authored
Virtual engines are fleeting. They carry a reference count and may be freed when their last request is retired. This makes them unsuitable for the task of housing engine->retire.work so assert that it is not used. Tvrtko tracked down an instance where we did indeed violate this rule. In virtual_submit_request, we flush a completed request directly with __i915_request_submit and this causes us to queue that request on the veng's breadcrumb list and signal it. Leading us down a path where we should not attach the retire. Reported-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.6-2020-02-05: amdgpu: - EDC fixes for Arcturus - GDDR6 memory training fixe - Fix for reading gfx clockgating registers while in GFXOFF state - i2c freq fixes - Misc display fixes - TLB invalidation fix when using semaphores - VCN 2.5 instancing fixes - Switch raven1 gfxoff to a blacklist - Coreboot workaround for KV/KB - Root cause dongle fixes for display and revert workaround - Enable GPU reset for renoir and navi - Navi overclocking fixes - Fix up confusing warnings in display clock validation on raven amdkfd: - SDMA fix radeon: - Misc LUT fixes Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200206035458.3894-1-alexander.deucher@amd.com
-
git://github.com/skeggsb/linuxDave Airlie authored
Just a couple of fixes to Volta/Turing modesetting on some systems. Signed-off-by:
-
git://anongit.freedesktop.org/tegra/linuxDave Airlie authored
drm/tegra: Fixes for v5.6-rc1 These are a couple of quick fixes for regressions that were found during the first two weeks of the merge window. Signed-off-by:
-
Matthew Auld authored
We already have tests that exhaustively exercise the most interesting page-size combinations, along with tests that offer randomisation, and so we should already be testing objects(local, system) with a varying mix of page-sizes, which leaves igt_ppgtt_exhaust_huge providing not much in terms of extra coverage. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
- 06 Feb, 2020 5 commits
-
-
José Roberto de Souza authored
TGL is suffering of timeouts and fifo underruns when disabling transcoder in MST mode, this is fixed by set TRANS_DDI_MODE_SELECT to 0(HDMI mode) when clearing DDI select. Although BSpec disable sequence don't require this step, it is a harmless change and it is also done by Windows driver. Anyhow HW team was notified about that but it can take some time to documentation to be updated. A case that always lead to those issues is: - do a modeset enabling pipe A and pipe B in the same MST stream leaving A as master - disable pipe A, promote B as master doing a full modeset in A - enable pipe A, changing the master transcoder back to A(doing a full modeset in B) - Pow: underruns and timeouts The transcoders involved will only work again when complete disabled and their power wells turned off causing a reset in their registers. v2: Setting TRANS_DDI_MODE_SELECT to default when clearing DDI select not anymore when disabling TRANS_DDI, both work but this one looks more safe. (Ville comment) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200203225549.152301-1-jose.souza@intel.com
-
Chris Wilson authored
Always prime the page table registers before starting the ring. Even though we will update these to the per-context page tables during dispatch, it is prudent to ensure that the registers always point to a valid PD. Signed-off-by:
-
Thierry Reding authored
The DMA direction is only used by the DMA API, so there is no use in setting it when a buffer object isn't mapped with the DMA API. Signed-off-by:
Thierry Reding <treding@nvidia.com> Tested-by:
Dmitry Osipenko <digetx@gmail.com> Reviewed-by:
-
Thierry Reding authored
This partially reverts the DMA API support that was recently merged because it was causing performance regressions on older Tegra devices. Unfortunately, the cache maintenance performed by dma_map_sg() and dma_unmap_sg() causes performance to drop by a factor of 10. The right solution for this would be to cache mappings for buffers per consumer device, but that's a bit involved. Instead, we simply revert to the old behaviour of sharing IOVA mappings when we know that devices can do so (i.e. they share the same IOMMU domain). Cc: <stable@vger.kernel.org> # v5.5 Reported-by:
-
Thierry Reding authored
Older Tegra devices only allow addressing 32 bits of memory, so whether or not the host1x is attached to an IOMMU doesn't matter. host1x IOMMU attachment is only needed on devices that can address memory beyond the 32-bit boundary and where the host1x doesn't support the wide GATHER opcode that allows it to access buffers at higher addresses. Cc: <stable@vger.kernel.org> # v5.5 Signed-off-by:
-
- 05 Feb, 2020 11 commits
-
-
Chris Wilson authored
Rather than flushing the submission tasklets just before we sleep, flush before we check the request status. Ideally this gives us a moment to process the tasklets after sleeping just before we timeout. v2: Compromise by pushing the flush prior to the timeout, but after the check on completion so that we do not further delay the ready client. Signed-off-by:
-
Chris Wilson authored
We have been using '-1' to mean the maximum i915.reset level in the belief that it was unsigned... This turns out to have been a grave error, and instead of setting the default reset mechanism in igt, we have been disabling reset! Signed-off-by:
-
Stanislav Lisovskiy authored
Added proper DBuf slice mapping to correspondent pipes, depending on pipe configuration as stated in BSpec. v2: - Remove unneeded braces - Stop using macro for DBuf assignments as it seems to reduce readability. v3: Start using enabled slices mask in dev_priv v4: Renamed "enabled_slices" used in dev_priv to "enabled_dbuf_slices_mask"(Matt Roper) v5: - Removed redundant parameters from intel_get_ddb_size function.(Matt Roper) - Made i915_possible_dbuf_slices static(Matt Roper) - Renamed total_width into total_width_in_range so that it now reflects that this is not a total pipe width but the one in current dbuf slice allowed range for pipe.(Matt Roper) - Removed 4th pipe for ICL in DBuf assignment table(Matt Roper) - Fixed wrong DBuf slice in DBuf table for TGL (Matt Roper) - Added comment regarding why we currently not using pipe ratio for DBuf assignment for ICL v6: - Changed u32 to unsigned int in icl_get_first_dbuf_slice_offset function signature (Ville Syrjälä) - Changed also u32 to u8 in dbuf slice mask structure (Ville Syrjälä) - Switched from DBUF_S1_BIT to enum + explicit BIT(DBUF_S1) access(Ville Syrjälä) - Switched to named initializers in DBuf assignment arrays(Ville Syrjälä) - DBuf assignment arrays now use autogeneration tool from https://patchwork.freedesktop.org/series/70493/ to avoid typos. - Renamed i915_find_pipe_conf to *_compute_dbuf_slices (Ville Syrjälä) - Changed platforms ordering in skl_compute_dbuf_slices to be from newest to oldest(Ville Syrjälä) v7: - Now ORing assigned DBuf slice config always with DBUF_S1 because slice 1 has to be constantly powered on. (Ville Syrjälä) v8: - Added pipe_name for neater printing(Ville Syrjälä) - Renamed width_before_pipe to width_before_pipe_in_range, to better reflect that now all the calculations are happening inside DBuf range allowed by current pipe configuration mask (Ville Syrjälä) - Shortened FIXME comment message, regarding constant ORing with DBUF_S1(Ville Syrjälä) - Added .dbuf_mask named initializer to pipe assignment array (Ville Syrjälä) - Edited pipe assignment array to use only single DBuf slice for gen11 single pipe configurations, until "pipe ratio" thing is finally sorted out(Ville Syrjälä) - Removed unused parameter crtc_state for now(Ville Syrjälä) from icl/tgl_compute_dbuf_slices function Reviewed-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
Start manipulating DBuf slices as a mask, but not as a total number, as current approach doesn't give us full control on all combinations of slices, which we might need(like enabling S2 only can't enabled by setting enabled_slices=1). Removed wrong code from intel_get_ddb_size as it doesn't match to BSpec. For now still just use DBuf slice until proper algorithm is implemented. Other minor code refactoring to get prepared for major DBuf assignment changes landed: - As now enabled slices contain a mask we still need some value which should reflect how much DBuf slices are supported by the platform, now device info contains num_supported_dbuf_slices. - Removed unneeded assertion as we are now manipulating slices in a more proper way. v2: Start using enabled_slices in dev_priv v3: "enabled_slices" is now "enabled_dbuf_slices_mask", as this now sits in dev_priv independently. v4: - Fixed debug print formatting to hex(Matt Roper) - Optimized dbuf slice updates to be used only if slice union is different from current conf(Matt Roper) - Fixed some functions to be static(Matt Roper) - Created a parameterized version for DBUF_CTL to simplify DBuf programming cycle(Matt Roper) - Removed unrequred field from GEN10_FEATURES(Matt Roper) v5: - Removed redundant programming dbuf slices helper(Ville Syrjälä) - Started to use parameterized loop for hw readout to get slices (Ville Syrjälä) - Added back assertion checking amount of DBUF slices enabled after DC states 5/6 transition, also added new assertion as starting from ICL DMC seems to restore the last DBuf power state set, rather than power up all dbuf slices as assertion was previously expecting(Ville Syrjälä) v6: - Now using enum for DBuf slices in this patch (Ville Syrjälä) - Removed gen11_assert_dbuf_enabled and put gen9_assert_dbuf_enabled back, as we really need to have a single unified assert here however currently enabling always slice 1 is enforced by BSpec, so we will have to OR enabled slices mask with 1 in order to be consistent with BSpec, that way we can unify that assertion and against the actual state from the driver, but not some hardcoded value.(concluded with Ville) - Remove parameterized DBUF_CTL version, to extract it to another patch.(Ville Syrjälä) v7: - Removed unneeded hardcoded return value for older gens from intel_enabled_dbuf_slices_mask - this now is handled in a unified manner since device info anyway returns max dbuf slices as 1 for older platforms(Matthew Roper) - Now using INTEL_INFO(dev_priv)->num_supported_dbuf_slices instead of intel_dbuf_max_slices function as it is trivial(Matthew Roper) v8: - Fixed icl_dbuf_disable to disable all dbufs still(Ville Syrjälä) v9: - Renamed _DBUF_CTL_S to DBUF_CTL_S(Ville Syrjälä) - Now using power_domain mutex to protect from race condition, which can occur because intel_dbuf_slices_update might be running in parallel to gen9_dc_off_power_well_enable being called from intel_dp_detect for instance, which causes assertion triggered by race condition, as gen9_assert_dbuf_enabled might preempt this when registers were already updated, while dev_priv was not. Reviewed-by: -
Stanislav Lisovskiy authored
Now start using parameterized DBUF_CTL instead of hardcoded, this would allow shorter access functions when reading or storing entire state. Tried to implement it in a MMIO_PIPE manner, however DBUF_CTL1 address is higher than DBUF_CTL2, which implies that we have to now subtract from base rather than add. v2: - Removed unneeded DBUF_CTL_DIST and DBUF_CTL_ADDR macros. Started to use _PICK construct as suggested by Matt Roper. v3: - _DBUF_CTL_S* to DBUF_CTL_S*, changed X to "slice" in macro(Ville Syrjälä) - Introduced enum for enumerating DBUF slices(Ville Syrjälä) Reviewed-by: -
Stanislav Lisovskiy authored
During full modeset, global state(i.e dev_priv) is protected by locking the crtcs in state, otherwise global state is not serialized. Also if it is not a full modeset, we anyway don't need to change DBuf slice configuration as Pipe configuration doesn't change. Reviewed-by:
-
Stanislav Lisovskiy authored
Current DBuf slices update wasn't done in proper place, especially its "post" part, which should disable those only once vblank had passed and all other changes are committed. v2: Fix to use dev_priv and intel_atomic_state instead of skl_ddb_values (to be nuked in Villes patch) v3: Renamed "enabled_slices" to "enabled_dbuf_slices_num" (Matt Roper) v4: - Rebase against drm-tip. - Move post_update closer to optimize_watermarks, to prevent unneeded noise from underrun reporting (Ville Syrjälä) Reviewed-by: -
Stanislav Lisovskiy authored
Current consensus that it is redundant as we already have skl_ddb_values struct out there, also this struct contains only single member which makes it unnecessary. v2: As dirty_pipes soon going to be nuked away from skl_ddb_values, evacuating enabled_slices to safer in dev_priv. v3: Changed "enabled_slices" to be "enabled_dbuf_slices_num" (Matt Roper) v4: - Wrapped the line getting number of dbuf slices(Matt Roper) - Removed indeed redundant skl_ddb_values declaration(Matt Roper) Reviewed-by: -
Chris Wilson authored
As only the display codes tries to pin its preallocated framebuffer into an exact location in the GGTT, remove the convenience function and make the pin management explicit in the display code. Then throughout the display management, we track the framebuffer and its plane->vma; with less single purpose code and ready for first class i915_vma. In doing so, this should fix the BUG_ON(vma->pages) on fi-kbl-soraka. Signed-off-by:
-
Chris Wilson authored
I am about to stuff more objects into the plane_config and would like to have it clean up after itself. Move the current framebuffer release into a common function so it can be extended with the new object with relative ease. Signed-off-by:
-
Jani Nikula authored
The DDI encoder code shouln't have to know about the guts of HDCP. Abstract the pipe update code to a new intel_hdcp_update_pipe() in intel_hdcp.c. No functional changes. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
