aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2020-05-13drm/i915: Make active_pipes check skl specificStanislav Lisovskiy2-6/+11
Seems that only skl needs to have SAGV turned off for multipipe scenarios, so lets do it this way. If anything blows up - we can always revert this patch. v2: Changed if condition to look better (Ville). Signed-off-by: Stanislav Lisovskiy <[email protected]> [vsyrjala: wrapped long line to appease checkpatch] Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-13drm/i915: Extract skl SAGV checkingStanislav Lisovskiy1-2/+8
Introduce platform dependent SAGV checking in combination with bandwidth state pipe SAGV mask. This is preparation to adding TGL support, which requires different way of SAGV checking. v2, v3, v4, v5, v6: Fix rebase conflict v7: - Nuke icl specific function, use skl for icl as well, gen specific active_pipes check to be added in the next patch(Ville) v8: - Use more generic intel_crtc_can_enable_sagv for checking(Ville) Signed-off-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-13drm/i915: Introduce skl_plane_wm_level accessor.Stanislav Lisovskiy1-2/+21
For future Gen12 SAGV implementation we need to seemlessly alter wm levels calculated, depending on whether we are allowed to enable SAGV or not. So this accessor will give additional flexibility to do that. Currently this accessor is still simply working as "pass-through" function. This will be changed in next coming patches from this series. v2: - plane_id -> plane->id(Ville Syrjälä) - Moved wm_level var to have more local scope (Ville Syrjälä) - Renamed yuv to color_plane(Ville Syrjälä) in skl_plane_wm_level v3: - plane->id -> plane_id(this time for real, Ville Syrjälä) - Changed colorplane id type from boolean to int as index (Ville Syrjälä) - Moved crtc_state param so that it is first now (Ville Syrjälä) - Moved wm_level declaration to tigher scope in skl_write_plane_wm(Ville Syrjälä) v4: - Started to use enum values for color plane - Do sizeof for a type what we are memset'ing - Zero out wm_uv as well(Ville Syrjälä) v5: - Fixed rebase conflict caused by COLOR_PLANE_* enum removal v6: - Do not use skl_plane_wm_level accessor in skl_allocate_pipe_ddb v7: - Get rid of wm_uv, which is not used in skl_plane_write_wm(Ville) Signed-off-by: Stanislav Lisovskiy <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-13drm/i915/gt: Reset execlists registers before HWSPChris Wilson1-7/+14
Upon gt resume, we first poison then sanitize the engine. However, our testing shows that gen9 will very rarely retain the poisoned value from the HWSP mappings of the execlists status registers. This suggests that it is reading back from the HWSP, so rejig the register reset. v2: Maybe RING_CONTEXT_STATUS_PTR is write masked. It is. References: https://gitlab.freedesktop.org/drm/intel/-/issues/1812 Signed-off-by: Chris Wilson <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-13drm/meson: pm resume add return errno branchBernard Zhao1-3/+1
pm_resump api did not handle drm_mode_config_helper_resume error. This change add handle to return drm_mode_config_helper_resume`s error number. This code logic is aligned with api pm_suspend. After this change, the code maybe a bit readable. Signed-off-by: Bernard Zhao <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-12drm/i915/ehl: Restrict w/a 1607087056 for EHL/JSLSwathi Dhanavanthri2-4/+12
This w/a is fixed in B0 stepping and needs to be restricted for A0 stepping only. Bspec: 33451 Signed-off-by: Swathi Dhanavanthri <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Signed-off-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-12drm/amd/amdgpu: Update update_config() logicLeo (Hanghong) Ma1-5/+5
[Why] For MST case: when update_config is called to disable a stream, this clears the settings for all the streams on that link. We should only clear the settings for the stream that was disabled. [How] Clear the settings after the call to remove display is called. Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Leo (Hanghong) Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-12drm/amd/amdgpu: add raven1 part to the gfxoff quirk listTom St Denis1-0/+2
On my raven1 system (rev c6) with VBIOS 113-RAVEN-114 GFXOFF is not stable (resulting in large block tiling noise in some applications). Disabling GFXOFF via the quirk list fixes the problems for me. Signed-off-by: Tom St Denis <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2020-05-12drm/i915: Handle idling during i915_gem_evict_something busy loopsChris Wilson1-14/+12
i915_gem_evict_something() is charged with finding a slot within the GTT that we may reuse. Since our goal is not to stall, we first look for a slot that only overlaps idle vma. To this end, on the first pass we move any active vma to the end of the search list. However, we only stopped moving active vma after we see the first active vma twice. If during the search, that first active vma completed, we would not notice and keep on extending the search list. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1746 Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex") Fixes: b1e3177bd1d8 ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.5+ Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-12drm/mcde: dsi: Fix return value check in mcde_dsi_bind()Wei Yongjun1-4/+3
The of_drm_find_bridge() function returns NULL on error, it doesn't return error pointers so this check doesn't work. Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") Signed-off-by: Wei Yongjun <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11Merge tag 'gvt-fixes-2020-05-12' of https://github.com/intel/gvt-linux into ↵Rodrigo Vivi2-6/+49
drm-intel-fixes gvt-fixes-2020-05-12 - Correct transcoder and DPLL initial clock to fix recent guest display probe failure. (Colin) - Fix kernel oops on older guest using aliasing ppgtt. (Zhenyu) Signed-off-by: Rodrigo Vivi <[email protected]> From: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/amd/amdgpu: remove defined but not used 'crtc_offsets'Jason Yan1-11/+0
Fix the following gcc warning: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:65:18: warning: ‘crtc_offsets’ defined but not used [-Wunused-const-variable=] static const u32 crtc_offsets[6] = ^~~~~~~~~~~~ Reported-by: Hulk Robot <[email protected]> Signed-off-by: Jason Yan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-11drm/amd/amdgpu: Update update_config() logicLeo (Hanghong) Ma1-5/+5
[Why] For MST case: when update_config is called to disable a stream, this clears the settings for all the streams on that link. We should only clear the settings for the stream that was disabled. [How] Clear the settings after the call to remove display is called. Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Bhawanpreet Lakha <[email protected]> Signed-off-by: Leo (Hanghong) Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-11drm/amd/amdgpu: Add missing GRBM bits for GFX 10.1Tom St Denis1-0/+4
Requested bits for UMR support Signed-off-by: Tom St Denis <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-11drm/amd/amdgpu: add raven1 part to the gfxoff quirk listTom St Denis1-0/+2
On my raven1 system (rev c6) with VBIOS 113-RAVEN-114 GFXOFF is not stable (resulting in large block tiling noise in some applications). Disabling GFXOFF via the quirk list fixes the problems for me. Signed-off-by: Tom St Denis <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-11drm/amd/powerplay: skip judging if baco support for Arcturus sriovJane Jian1-1/+1
since for sriov, baco happens on host side, no need and meaning to judge is baco. also, since kiq reads strap0 in here, if kiq is not ready or gpu reset(kiq resume) happens after this read, would fail to read and wrongly set baco as true(1). Acked-by: Evan Quan <[email protected]> Signed-off-by: Jane Jian <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-11drm/i915: Mark concurrent submissions with a weak-dependencyChris Wilson5-6/+15
We recorded the dependencies for WAIT_FOR_SUBMIT in order that we could correctly perform priority inheritance from the parallel branches to the common trunk. However, for the purpose of timeslicing and reset handling, the dependency is weak -- as we the pair of requests are allowed to run in parallel and not in strict succession. The real significance though is that this allows us to rearrange groups of WAIT_FOR_SUBMIT linked requests along the single engine, and so can resolve user level inter-batch scheduling dependencies from user semaphores. Fixes: c81471f5e95c ("drm/i915: Copy across scheduler behaviour flags across submit fences") Testcase: igt/gem_exec_fence/submit Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: <[email protected]> # v5.6+ Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 6b6cd2ebd8d071e55998e32b648bb8081f7f02bb) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-05-11drm/i915: Propagate error from completed fencesChris Wilson1-1/+3
We need to preserve fatal errors from fences that are being terminated as we hook them up. Fixes: ef4688497512 ("drm/i915: Propagate fence errors") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Matthew Auld <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 24fe5f2ab2478053d50a3bc629ada895903a5cbc) Signed-off-by: Rodrigo Vivi <[email protected]>
2020-05-11drm/i915/gt: Restore Cherryview back to full-ppgttChris Wilson2-1/+55
This reverts commit 0b718ba1e884f64dce27c19311dd2859b87e56b9. There are still some residual issues with asynchronous binding and execution, but since commit 92581f9fb99c ("drm/i915: Immediately execute the fenced work") we prefer not to use asynchronous binds, and the remaining issues do not seem restricted to Cherryview [at least the ones seen over a few dozen CI runs, less frequent issues are sure to be discovered!] These issues seem to be mitigated, if not eliminated entirely, by the previous commit 84eac0c65940 ("drm/i915/gt: Force pte cacheline to main memory"). Signed-off-by: Chris Wilson <[email protected]> Acked-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915/gt: Force pte cacheline to main memoryMika Kuoppala1-2/+13
We have problems of tgl not seeing a valid pte entry when iommu is enabled. Add heavy handed flushing of entry modification by flushing the cpu, cacheline and then wcb. This forces the pte out to main memory past this point regarless of promises of coherency. This is an evolution of an experimental patch from Chris Wilson of adding wmb for coherent partners, by adding a clflush to force the cache->memory step. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1840 Testcase: igt/gem_exec_fence/parallel Signed-off-by: Mika Kuoppala <[email protected]> Cc: Chris Wilson <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915: Remove unused HAS_FWTABLE macroPascal Terjan1-5/+0
It has been unused since commit ccb2aceaaa5f ("drm/i915: use vfuncs for reg_read/write_fw_domains"). Signed-off-by: Pascal Terjan <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915/selftests: Always flush before unpining after writingChris Wilson7-4/+21
Be consistent, and even when we know we had used a WC, flush the mapped object after writing into it. The flush understands the mapping type and will only clflush if !I915_MAP_WC, but will always insert a wmb [sfence] so that we can be sure that all writes are visible. v2: Add the unconditional wmb so we are know that we always flush the writes to memory/HW at that point. Signed-off-by: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915: Emit await(batch) before MI_BB_STARTChris Wilson4-54/+64
Be consistent and ensure that we always emit the asynchronous waits prior to issuing instructions that use the address. This ensures that if we do emit GPU commands to do the await, they are before our use! Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Embed connector instance in struct mga_deviceThomas Zimmermann2-24/+33
Storing the connector instance in struct mga_device avoids some dynamic memory allocation. On errors, the connector's initializer function now destroys the i2c structure. Done in preparation of converting mgag200 to simple-KMS helpers. v2: * improved commit message (Michael) * fixed error message for mgag200_vga_connector_init() (Sam) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Michael J. Ruhl <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: John Donnelly <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Remove unused fields from struct mga_deviceThomas Zimmermann3-17/+0
The fields mode_info, num_crtcs and mode in struct mga_device serve no purpose. Remove them. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: John Donnelly <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Use managed mode-config initializationThomas Zimmermann3-32/+31
Mode configuration is now cleanued up automatically. While at it, move all mode-config code into mgag200_mode.c. Done in preparation of switching mgag200 to simple-KMS helpers. v2: * improve commit message (Sam) * rebased during cherry pick * also move bpp_shift initialization Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Tested-by: John Donnelly <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Integrate init function into load functionThomas Zimmermann1-40/+19
Done to simplify initialization code before embedding the DRM device instance in struct mga_device. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Remove several references to struct mga_device.devThomas Zimmermann2-19/+21
Done in preparation of embedding the DRM device in struct mga_device. This patch makes the patch for embedding more readable. v2: * improved commit message (Daniel) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/mgag200: Convert struct drm_device to struct mga_device with helperThomas Zimmermann6-19/+24
Mgag200 uses dev_private to look up struct mga_device for instances of struct drm_device. Use of dev_private is deprecated, so hide it in the helper function to_mga_device(). v2: * make to_mga_device() a function (Sam) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11mm/hmm: remove the customizable pfn format from hmm_range_faultJason Gunthorpe4-81/+71
Presumably the intent here was that hmm_range_fault() could put the data into some HW specific format and thus avoid some work. However, nothing actually does that, and it isn't clear how anything actually could do that as hmm_range_fault() provides CPU addresses which must be DMA mapped. Perhaps there is some special HW that does not need DMA mapping, but we don't have any examples of this, and the theoretical performance win of avoiding an extra scan over the pfns array doesn't seem worth the complexity. Plus pfns needs to be scanned anyhow to sort out any DEVICE_PRIVATE pages. This version replaces the uint64_t with an usigned long containing a pfn and fixed flags. On input flags is filled with the HMM_PFN_REQ_* values, on successful output it is filled with HMM_PFN_* values, describing the state of the pages. amdgpu is simple to convert, it doesn't use snapshot and doesn't use per-page flags. nouveau uses only 16 hmm_pte entries at most (ie fits in a few cache lines), and it sweeps over its pfns array a couple of times anyhow. It also has a nasty call chain before it reaches the dma map and hardware suggesting performance isn't important: nouveau_svm_fault(): args.i.m.method = NVIF_VMM_V0_PFNMAP nouveau_range_fault() nvif_object_ioctl() client->driver->ioctl() struct nvif_driver nvif_driver_nvkm: .ioctl = nvkm_client_ioctl nvkm_ioctl() nvkm_ioctl_path() nvkm_ioctl_v0[type].func(..) nvkm_ioctl_mthd() nvkm_object_mthd() struct nvkm_object_func nvkm_uvmm: .mthd = nvkm_uvmm_mthd nvkm_uvmm_mthd() nvkm_uvmm_mthd_pfnmap() nvkm_vmm_pfn_map() nvkm_vmm_ptes_get_map() func == gp100_vmm_pgt_pfn struct nvkm_vmm_desc_func gp100_vmm_desc_spt: .pfn = gp100_vmm_pgt_pfn nvkm_vmm_iter() REF_PTES == func == gp100_vmm_pgt_pfn() dma_map_page() Link: https://lore.kernel.org/r/[email protected] Acked-by: Felix Kuehling <[email protected]> Tested-by: Ralph Campbell <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-11mm/hmm: remove HMM_PFN_SPECIALJason Gunthorpe2-2/+0
This is just an alias for HMM_PFN_ERROR, nothing cares that the error was because of a special page vs any other error case. Link: https://lore.kernel.org/r/[email protected] Acked-by: Felix Kuehling <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Reviewed-by: John Hubbard <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-11drm/amdgpu: remove dead code after hmm_range_fault()Jason Gunthorpe1-10/+6
Since amdgpu does not use the snapshot mode of hmm_range_fault() a successful return already proves that all entries in the pfns are HMM_PFN_VALID, there is no need to check the return result of hmm_device_entry_to_page(). Link: https://lore.kernel.org/r/[email protected] Acked-by: Felix Kuehling <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-11mm/hmm: make hmm_range_fault return 0 or -1Jason Gunthorpe2-5/+5
hmm_vma_walk->last is supposed to be updated after every write to the pfns, so that it can be returned by hmm_range_fault(). However, this is not done consistently. Fortunately nothing checks the return code of hmm_range_fault() for anything other than error. More importantly last must be set before returning -EBUSY as it is used to prevent reading an output pfn as an input flags when the loop restarts. For clarity and simplicity make hmm_range_fault() return 0 or -ERRNO. Only set last when returning -EBUSY. Link: https://lore.kernel.org/r/[email protected] Acked-by: Felix Kuehling <[email protected]> Tested-by: Ralph Campbell <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2020-05-11drm/i915: Use stashed away hpd isr bits in intel_digital_port_connected()Ville Syrjälä3-134/+17
Get rid of several platform specific variants of intel_digital_port_connected() and just use the ISR bits we've stashed away. v2: Duplicate stuff to avoid exposing platform specific functions across files (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2020-05-11drm/i915: Stash hpd status bits under dev_privVille Syrjälä2-89/+116
Instead of constnantly having to figure out which hpd status bit array to use let's store them under dev_priv. Should perhaps take this further and stash even more stuff to make the hpd handling more abstract yet. v2: Remeber cnp (Imre) Add MISSING_CASE() for unknown PCHs (Imre) Cc: Imre Deak <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2020-05-11drm/i915: Turn intel_digital_port_connected() in a vfuncVille Syrjälä5-128/+135
Let's get rid of the platform if ladders in intel_digital_port_connected() and make it a vfunc. Now the if ladders are at the encoder initialization which makes them a bit less convoluted. v2: Add forward decl for intel_encoder in intel_tc.h v3: Duplicate stuff to avoid exposing platform specific functions across files (Jani) Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2020-05-11drm/i915: Fix glk watermark calculationsVille Syrjälä1-7/+8
GLK wants the +1 adjustement for the "blocks per line" value for x-tile/y-tile, just like cnl+. Also the x-tile and linear cases are almost identical. The only difference is this +1 which is always done for glk+, and only done for linear on skl/bxt. Let's unify it to a single branch with a special case for the +1, just like we do for y-tile. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy <[email protected]>
2020-05-11drm/i915/mst: Wait for ACT sent before enabling the pipeVille Syrjälä1-4/+5
The correct sequence according to bspec is to wait for the ACT sent status before we turn on the pipe. Make it so. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2020-05-11drm/i915: Tidy awaiting on dma-fencesChris Wilson1-6/+4
Just tidy up the return handling for completed dma-fences. While it may return errors for invalid fence, we already know that we have a good fence and the only error will be an already signaled fence. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915: Make intel_timeline_init staticMika Kuoppala2-9/+4
Commit fb5970da1b42 ("drm/i915/gt: Use the kernel_context to measure the breadcrumb size") removed the last external user for intel_timeline_init. Mark it static. Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915/gt: Mark up the racy read of execlists->context_tagChris Wilson1-1/+1
Since we are using bitops on context_tag to allow us to reserve and release inflight tags concurrently, the scan for the next bit is intentionally racy. [ 516.446854] BUG: KCSAN: data-race in execlists_schedule_in.isra.0 [i915] / execlists_schedule_out [i915] [ 516.446874] [ 516.446886] write (marked) to 0xffff8881f7644048 of 8 bytes by interrupt on cpu 2: [ 516.447076] execlists_schedule_out+0x538/0x6a0 [i915] [ 516.447263] process_csb+0x10b/0x3d0 [i915] [ 516.447449] execlists_submission_tasklet+0x30/0x170 [i915] [ 516.447468] tasklet_action_common.isra.0+0x42/0x90 [ 516.447484] __do_softirq+0xc8/0x206 [ 516.447498] irq_exit+0xcd/0xe0 [ 516.447516] do_IRQ+0x44/0xc0 [ 516.447535] ret_from_intr+0x0/0x1c [ 516.447550] cpuidle_enter_state+0x199/0x400 [ 516.447572] cpuidle_enter+0x50/0x90 [ 516.447587] do_idle+0x197/0x1e0 [ 516.447600] cpu_startup_entry+0x14/0x20 [ 516.447619] start_secondary+0xf9/0x130 [ 516.447643] secondary_startup_64+0xa4/0xb0 [ 516.447655] [ 516.447671] read to 0xffff8881f7644048 of 8 bytes by task 460 on cpu 1: [ 516.447863] execlists_schedule_in.isra.0+0x3cf/0x5a0 [i915] [ 516.448064] execlists_dequeue+0xf8f/0x1690 [i915] [ 516.448252] __execlists_submission_tasklet+0x48/0x60 [i915] [ 516.448440] execlists_submit_request+0x2e2/0x310 [i915] [ 516.448634] submit_notify+0x8f/0xc8 [i915] [ 516.448820] __i915_sw_fence_complete+0x61/0x420 [i915] [ 516.449005] i915_sw_fence_complete+0x58/0x80 [i915] [ 516.449208] i915_sw_fence_commit+0x16/0x20 [i915] [ 516.449399] __i915_request_queue+0x60/0x70 [i915] [ 516.449590] i915_gem_do_execbuffer+0x33f1/0x4a00 [i915] [ 516.449782] i915_gem_execbuffer2_ioctl+0x2a2/0x550 [i915] [ 516.449800] drm_ioctl_kernel+0xe9/0x130 [ 516.449814] drm_ioctl+0x27d/0x45e [ 516.449827] ksys_ioctl+0x89/0xb0 [ 516.449842] __x64_sys_ioctl+0x42/0x60 [ 516.449864] do_syscall_64+0x6e/0x2c0 [ 516.449878] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-11drm/i915/gvt: Fix kernel oops for 3-level ppgtt guestZhenyu Wang1-1/+5
As i915 won't allocate extra PDP for current default PML4 table, so for 3-level ppgtt guest, we would hit kernel pointer access failure on extra PDP pointers. So this trys to bypass that now. It won't impact real shadow PPGTT setup, so guest context still works. This is verified on 4.15 guest kernel with i915.enable_ppgtt=1 to force on old aliasing ppgtt behavior. Fixes: 4f15665ccbba ("drm/i915: Add ppgtt to GVT GEM context") Reviewed-by: Xiong Zhang <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-09drm/i2c/tda998x: Make tda998x_audio_digital_mute staticSamuel Zou1-1/+2
Fix the following sparse warning: drivers/gpu/drm/i2c/tda998x_drv.c:1136:5: warning: symbol 'tda998x_audio_digital_mute' was not declared. Should it be static? Reported-by: Hulk Robot <[email protected]> Signed-off-by: Samuel Zou <[email protected]> Cc: Russell King <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-09drm/panel-simple: Support hpd-gpios for delaying prepare()Douglas Anderson1-0/+53
People use panel-simple when they have panels that are builtin to their device. In these cases the HPD (Hot Plug Detect) signal isn't really used for hotplugging devices but instead is used for power sequencing. Panel timing diagrams (especially for eDP panels) usually have the HPD signal in them and it acts as an indicator that the panel is ready for us to talk to it. Sometimes the HPD signal is hooked up to a normal GPIO on a system. In this case we need to poll it in the correct place to know that the panel is ready for us. In some system designs the right place for this is panel-simple. When adding this support, we'll account for the case that there might be a circular dependency between panel-simple and the provider of the GPIO. The case this was designed for was for the "ti-sn65dsi86" bridge chip. If HPD is hooked up to one of the GPIOs provided by the bridge chip then in our probe function we'll always get back -EPROBE_DEFER. Let's handle this by allowing this GPIO to show up late if we saw -EPROBE_DEFER during probe. NOTE: since the gpio_get_optional() is used, if the "hpd-gpios" isn't there our variable will just be NULL and we won't do anything in prepare(). Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200507143354.v5.3.I53fed5b501a31e7a7fa13268ebcdd6b77bd0cadd@changeid
2020-05-09panel: simple: Add BOE NV133FHM-N62Douglas Anderson1-0/+5
All info I could find about this panel show that it behaves the same as the BOE NV133FHM-N61. However, it definitely appears to be a unique panel because reading the EDID shows "NV133FHM-N62". We'll add a string match for the new panel but until we find something unique about it we'll just point at the N61's structures. Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.3.I525ebd471f5340a6a369af7bde06ef04174d2f41@changeid
2020-05-09panel: simple: Fix size and bpp of BOE NV133FHM-N61Douglas Anderson1-3/+3
The BOE NV133FHM-N61 is documented in the original commit to be a 13.3" panel, but the size listed in our struct doesn't match. Specifically: math.sqrt(30.0 * 30.0 + 18.7 * 18.7) / 2.54 ==> 13.92 Searching around on the Internet shows that the size that was in the structure was the "Outline Size", not the "Display Area". Let's fix it. Also the Internet says that this panel supports 262K colors. That's 6bpp, not 8bpp. Fixes: b0c664cc80e8 ("panel: simple: Add BOE NV133FHM-N61") Signed-off-by: Douglas Anderson <[email protected]> Signed-off-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200508155859.1.I4d29651c0837b4095fb4951253f44036a371732f@changeid
2020-05-09drm/i915: Replace zero-length array with flexible-arrayGustavo A. R. Silva3-4/+4
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20200507185408.GA14561@embeddedor
2020-05-09drm/i915: Replace the hardcoded I915_FENCE_TIMEOUTChris Wilson9-9/+46
Expose the hardcoded timeout for unsignaled foreign fences as a Kconfig option, primarily to allow brave systems to disable the timeout and solely rely on correct signaling. Signed-off-by: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Acked-by: Michael J. Ruhl <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-09drm/i915/gvt: Init DPLL/DDI vreg for virtual display instead of inheritance.Colin Xu1-5/+44
Init value of some display vregs rea inherited from host pregs. When host display in different status, i.e. all monitors unpluged, different display configurations, etc., GVT virtual display setup don't consistent thus may lead to guest driver consider display goes malfunctional. The added init vreg values are based on PRMs and fixed by calcuation from current configuration (only PIPE_A) and the virtual EDID. Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization") Acked-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-05-08drm/amd/display: add basic atomic check for cursor planeSimon Ser1-2/+24
This patch adds a basic cursor check when an atomic test-only commit is performed. The position and size of the cursor plane is checked. This should fix user-space relying on atomic checks to assign buffers to planes. Signed-off-by: Simon Ser <[email protected]> Reported-by: Roman Gilg <[email protected]> References: https://github.com/emersion/libliftoff/issues/46 Cc: Alex Deucher <[email protected]> Cc: Harry Wentland <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
Powered by cgit, Gruvboxed by Blaster4385.