aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-22drm/nouveau/debugfs: fix runtime pm imbalance on errorDinghao Liu1-1/+4
pm_runtime_get_sync() increments the runtime PM usage counter even the call returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/nouveau/hmm: fix migrate zero page to GPURalph Campbell1-9/+66
When calling OpenCL clEnqueueSVMMigrateMem() on a region of memory that is backed by pte_none() or zero pages, migrate_vma_setup() will fill the source PFN array with an entry indicating the source page is zero. Use this to optimize migration to device private memory by allocating GPU memory and zero filling it instead of failing to migrate the page. Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/nouveau/hmm: fix nouveau_dmem_chunk allocationsRalph Campbell1-192/+112
In nouveau_dmem_init(), a number of struct nouveau_dmem_chunk are allocated and put on the dmem->chunk_empty list. Then in nouveau_dmem_pages_alloc(), a nouveau_dmem_chunk is removed from the list and GPU memory is allocated. However, the nouveau_dmem_chunk is never removed from the chunk_empty list nor placed on the chunk_free or chunk_full lists. This results in only one chunk ever being actually used (2MB) and quickly leads to migration to device private memory failures. Fix this by having just one list of free device private pages and if no pages are free, allocate a chunk of device private pages and GPU memory. Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MSTLyude Paul5-20/+75
Currently, the nv50_mstc_mode_valid() function is happy to take any and all modes, even the ones we can't actually support sometimes like interlaced modes. Luckily, the only difference between the mode validation that needs to be performed for MST vs. SST is that eventually we'll need to check the minimum PBN against the MSTB's full PBN capabilities (remember-we don't care about the current bw state here). Otherwise, all of the other code can be shared. So, we move all of the common mode validation in nouveau_connector_mode_valid() into a separate helper, nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and nouveau_connector_mode_valid(). Note that we allow for returning the calculated clock that nv50_dp_mode_valid() came up with, since we'll eventually want to use that for PBN calculation in nv50_mstc_mode_valid(). Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes()Lyude Paul1-11/+14
This just limits the BPC for MST connectors to a maximum of 8 from nv50_mstc_get_modes(), instead of doing so during nv50_msto_atomic_check(). This doesn't introduce any functional changes yet (other then userspace now lying about the max bpc, but we can't support that yet anyway so meh). But, we'll need this in a moment so that we can share mode validation between SST and MST which will fix some real world issues. Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms/gv100-: Add support for interlaced modesLyude Paul2-4/+6
We advertise being able to set interlaced modes, so let's actually make sure to do that. Otherwise, we'll end up hanging the display engine due to trying to set a mode with timings adjusted for interlacing without telling the hardware it's actually an interlaced mode. Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing supportLyude Paul15-3/+118
Right now, we make the mistake of allowing interlacing on all connectors. Nvidia hardware does not always support interlacing with DP though, so we need to make sure that we don't allow interlaced modes to be set in such situations as otherwise we'll end up accidentally hanging the display HW. This fixes some hangs with Turing, which would be caused by attempting to set an interlaced mode on hardware that doesn't support it. This patch likely fixes other hardware hanging in the same way as well. Note that we say we probe PIOR caps, but they don't actually have any interlacing caps. So, the get_caps() function for PIORs just sets interlacing support to true. Changes since v1: * Actually probe caps correctly this time, both on EVO and NVDisplay. Changes since v2: * Fix probing for < GF119 * Use vfunc table, in prep for adding more caps in the future. Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create()Lyude Paul1-1/+4
We'll need the core channel initialized and ready by the time that we start creating modesetting objects, so that we can call the NV507D_GET_CAPABILITIES method to make the hardware expose it's modesetting capabilities for later probing. So, when loading the driver prepare the core channel from within nouveau_display_create(). Everywhere else, we initialize the core channel during resume. Signed-off-by: Lyude Paul <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/hda/gv100-: NV_PDISP_SF_AUDIO_CNTRL0 register movedBen Skeggs5-2/+35
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/hda/gf119-: select HDA device entry based on bound headBen Skeggs1-3/+4
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/hda/gf119-: add HAL for programming device entry in SFBen Skeggs8-2/+17
Register has moved on GV100. Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/hda/gt215-: pass head to nvkm_ior.hda.eld()Ben Skeggs4-6/+6
We're going to use the bound head to select HDA device entry. Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/nv50-: increase timeout on pio channel free() pollingBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Fix regression by audio component transitionTakashi Iwai1-6/+10
Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support"), the nouveau driver notifies and pokes the HD-audio HPD and ELD via audio component, but this seems broken. The culprit is the naive assumption that crtc->index corresponds to the HDA pin. Actually this rather corresponds to the MST dev_id (alias "pipe" in the audio component framework) while the actual port number is given from the output ior id number. This patch corrects the assignment of port and dev_id arguments in the audio component ops to recover from the HDMI/DP audio regression. Fixes: 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223 Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/device: use regular PRI accessors in chipset detectionBen Skeggs1-18/+13
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/device: detect vGPUsKarol Herbst1-3/+12
Using ENODEV as this prevents probe failed errors in dmesg. v2: move check further down Signed-off-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/device: detect if changing endianness failedKarol Herbst1-5/+21
v2: relax the checks a little Signed-off-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/device: rework mmio mapping code to get rid of second mapKarol Herbst1-12/+15
Fixes warnings on GPUs with smaller a smaller mmio region like vGPUs. Signed-off-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/mmu: Remove unneeded semicolonZheng Bin2-2/+2
Fixes coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h:307:2-3: Unneeded semicolon drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:583:2-3: Unneeded semicolon Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zheng Bin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau: Use generic helper to check _PR3 presenceKai-Heng Feng1-34/+10
Replace nouveau_pr3_present() in favor of a more generic one, pci_pr3_present(). Also the presence of upstream bridge _PR3 doesn't need to go hand in hand with device's _DSM, so check _PR3 before _DSM. Signed-off-by: Kai-Heng Feng <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/acr: Use kmemdup instead of kmalloc and memcpyZou Wei1-8/+4
Fixes coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity for kmemdup drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity for kmemdup Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Reported-by: Hulk Robot <[email protected]> Signed-off-by: Zou Wei <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/core/memory: remove redundant assignments to variable retColin Ian King1-1/+1
The variable ret is being initialized with a value that is never read and it is being updated later with a new value. The initialization is redundant and can be removed. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/svm: map pages after migrationRalph Campbell4-17/+95
When memory is migrated to the GPU, it is likely to be accessed by GPU code soon afterwards. Instead of waiting for a GPU fault, map the migrated memory into the GPU page tables with the same access permissions as the source CPU page table entries. This preserves copy on write semantics. Signed-off-by: Ralph Campbell <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: "Jérôme Glisse" <[email protected]> Cc: Ben Skeggs <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/disp/gv100-: expose capabilities classBen Skeggs6-0/+69
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/bios: move ACPI _ROM handlingBen Skeggs3-76/+47
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()Ben Skeggs1-28/+3
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/gr/gk20a: move MODULE_FIRMWARE firmware definitionsBen Skeggs2-11/+11
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/ibus: use nvkm_subdev_new_()Ben Skeggs6-30/+6
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/core: add nvkm_subdev_new_() for bare subdevsBen Skeggs2-0/+13
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Support NVIDIA format modifiersJames Jones3-9/+104
Allow setting the block layout of a nouveau FB object using DRM format modifiers. When specified, the format modifier block layout and kind overrides the GEM buffer's implicit layout and kind. The specified format modifier is validated against the list of modifiers supported by the target display hardware. v2: Used Tesla family instead of NV50 chipset compare v4: Do not cache kind, tile_mode in nouveau_framebuffer v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Check framebuffer size against boJames Jones1-0/+98
Make sure framebuffer dimensions and tiling parameters will not result in accesses beyond the end of the GEM buffer they are bound to. v3: Return EINVAL when creating FB against BO with unsupported tiling v5: Resolved against nouveau_framebuffer cleanup Signed-off-by: James Jones <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Add format mod prop to base/ovly/nvdispJames Jones6-4/+112
Advertise support for the full list of format modifiers supported by each class of NVIDIA desktop GPU display hardware. Stash the array of modifiers in the nouveau_display struct for use when validating userspace framebuffer creation requests, which will be supportd in a subsequent change. Signed-off-by: James Jones <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/acr: ensure falcon providing acr functions is bootstrapped firstBen Skeggs1-0/+5
Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Remove struct nouveau_framebufferThomas Zimmermann4-38/+28
After its cleanup, struct nouveau_framebuffer is only a wrapper around struct drm_framebuffer. Use the latter directly. Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Remove field nvbo from struct nouveau_framebufferThomas Zimmermann7-84/+75
The buffer object stored in nvbo is also available GEM object in obj[0] of struct drm_framebuffer. Therefore remove nvbo in favor obj[0] and replace all references accordingly. This may require an additional cast. With this change we can already replace nouveau_user_framebuffer_destroy() and nouveau_user_framebuffer_create_handle() with generic GEM helpers. Calls to nouveau_framebuffer_new() receive a GEM object. Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Move struct nouveau_framebuffer.vma to struct nouveau_fbdevThomas Zimmermann5-14/+14
The vma field of struct nouveau_framebuffer is a special field for the the accelerated fbdev console. Hence there's at most one single instance for the active console. Moving it into struct nouveau_fbdev makes struct nouveau_framebuffer slightly smaller and brings it closer to struct drm_framebuffer. Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau/kms: Remove unused fields from struct nouveau_framebufferThomas Zimmermann1-5/+0
Signed-off-by: Thomas Zimmermann <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm/nouveau: fix out-of-tree module buildBen Skeggs1-4/+6
The $(srctree) addition a while back busted building the out-of-tree version of the module, and I've been hacking it up ever since. This allows us to work around the issue. Signed-off-by: Ben Skeggs <[email protected]>
2020-05-22drm: Generalized NV Block Linear DRM format modJames Jones1-8/+114
Builds upon the existing NVIDIA 16Bx2 block linear format modifiers by adding more "fields" to the existing parameterized DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK format modifier macro that allow fully defining a unique-across- all-NVIDIA-hardware bit layout using a minimal set of fields and values. The new modifier macro DRM_FORMAT_MOD_NVIDIA_BLOCK_LINEAR_2D is effectively backwards compatible with the existing macro, introducing a superset of the previously definable format modifiers. Backwards compatibility has two quirks. First, the zero value for the "kind" field, which is implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK macro, must be special cased in drivers and assumed to map to the pre-Turing generic kind of 0xfe, since a kind of "zero" is reserved for linear buffer layouts on all GPUs. Second, it is assumed backwards compatibility is only needed when running on Tegra GPUs, and specifically Tegra GPUs prior to Xavier. This is based on two assertions: -Tegra GPUs prior to Xavier used a slightly different raw bit layout than desktop GPUs, making it impossible to directly share block linear buffers between the two. -Support for the existing block linear modifiers was incomplete, making them useful only for exporting buffers created by nouveau and importing them to Tegra DRM as framebuffers for scan out. There was no support for adding framebuffers using format modifiers in nouveau, nor importing dma-buf/PRIME GEM objects into nouveau userspace drivers with modifiers in Mesa. Hence it is assumed the prior modifiers were not intended for use on desktop GPUs, and as a corollary, were not intended to support sharing block linear buffers across two different NVIDIA GPUs. v2: - Added canonicalize helper function v3: - Added additional bit to compression field to support Tesla (NV5x,G8x,G9x,GT1xx,GT2xx) class chips. Signed-off-by: James Jones <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-05-21drm/amdgpu: resize VRAM BAR for CPU access on gfx10Alan Swanson1-4/+10
Try to resize BAR0 to let CPU access all of VRAM on Navi. Syncs code with previous gfx generations from commit d6895ad39f3b39 ("drm/amdgpu: resize VRAM BAR for CPU access v6"). Signed-off-by: Alan Swanson <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amdgpu: drop navi pcie bw callbackAlex Deucher1-8/+0
It's not implemented yet so just drop it so the sysfs pcie bw file returns an appropriate error instead of garbage. Reviewed-by: Yong Zhao <[email protected]> Reviewed-By: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amdgpu: improve error handling in pcie_bwAlex Deucher1-1/+7
1. Initialize the counters to 0 in case the callback fails to initialize them. 2. The counters don't exist on APUs so return an error for them. 3. Return an error if the callback doesn't exist. Reviewed-by: Yong Zhao <[email protected]> Reviewed-By: Kent Russell <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amdkfd: fix restore worker race conditionPhilip Yang1-3/+3
In free memory of gpu path, remove bo from validate_list to make sure restore worker don't access the BO any more, then unregister bo MMU interval notifier. Otherwise, the restore worker will crash in the middle of validating BO user pages if MMU interval notifer is gone. Signed-off-by: Philip Yang <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amdgpu: off by one in amdgpu_device_attr_create_groups() error handlingDan Carpenter1-2/+1
This loop in the error handling code should start a "i - 1" and end at "i == 0". Currently it starts a "i" and ends at "i == 1". The result is that it removes one attribute that wasn't created yet, and leaks the zeroeth attribute. Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code") Acked-by: Michael J. Ruhl <[email protected]> Reviewed-by: Christian König <[email protected]> Reviewed-by: Kevin Wang <[email protected]> Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amdgpu/smu10: Replace one-element array and use struct_size() helperGustavo A. R. Silva2-5/+3
The current codebase makes use of one-element arrays in the following form: struct something { int length; u8 data[1]; }; struct something *instance; instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL); instance->length = size; memcpy(instance->data, source, size); 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. So, replace the one-element array with a flexible-array member. Also, make use of the new struct_size() helper to properly calculate the size of struct smu10_voltage_dependency_table. This issue was found with the help of Coccinelle and, audited and fixed _manually_. [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") Acked-by: Christian König <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amd/display: Set/Reset avmute when disable/enable streamJinze Xu1-0/+8
[Why] When disconnect fe from be, something such as unstable clock may cause garbage occurs. [How] Send set avmute at the beginning of disable stream and send reset avmute at the end of enable stream. Signed-off-by: Jinze Xu <[email protected]> Reviewed-by: Anthony Koo <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Acked-by: Tony Cheng <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amd/display: Fix incorrectly pruned modes with deep colorStylon Wang1-38/+64
[Why] When "max bpc" is set to enable deep color, some modes are removed from the list if they fail validation on max bpc. These modes should be kept if they validates fine with lower bpc. [How] - Retry with lower bpc in mode validation. - Same in atomic commit to apply working bpc, not necessarily max bpc. Signed-off-by: Stylon Wang <[email protected]> Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amd/display: correct rn NUM_VMIDDmytro Laktyushkin4-9/+9
Save the correct num vmid during resource creation and fix RN gpuvm level from 1 to 16 vmid entries. Signed-off-by: Dmytro Laktyushkin <[email protected]> Reviewed-by: Eric Bernstein <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amd/display: Avoid pipe split when plane is too smallNicholas Kazlauskas2-2/+33
[Why] The minimum plane size we can support in DML is 16x16. If we try to pass a 16x16 plane with dynamic pipe split then validation will fail since it tries to split it into two pipes, each 8x8. Some userspace doesn't check that the commit fails and because the commit fails the old state is retained, resulting in corruption. [How] Add a workaround to avoid pipe split if any plane is 16x16 or smaller. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-05-21drm/amd/display: Defer cursor lock until after VUPDATENicholas Kazlauskas6-1/+81
[Why] We dropped the delay after changed the cursor functions locking the entire pipe to locking just the CURSOR registers to fix page flip stuttering - this introduced cursor stuttering instead, and an underflow issue. The cursor update can be delayed indefinitely if the cursor update repeatedly happens right around VUPDATE. The underflow issue can happen if we do a viewport update on a pipe on the same frame where a cursor update happens around VUPDATE - the old cursor registers are retained which can be in an invalid position. This can cause a pipe hang and indefinite underflow. [How] The complex, ideal solution to the problem would be a software triple buffering mechanism from the DM layer to program only one cursor update per frame just before VUPDATE. The simple workaround until we have that infrastructure in place is this change - bring back the delay until VUPDATE before locking, but with some corrections to the calculations. This didn't work for all timings before because the calculation for VUPDATE was wrong - it was using the offset from VSTARTUP instead and didn't correctly handle the case where VUPDATE could be in the back porch. Add a new hardware sequencer function to use the existing helper to calculate the real VUPDATE start and VUPDATE end - VUPDATE can last multiple lines after all. Change the udelay to incorporate the width of VUPDATE as well. Signed-off-by: Nicholas Kazlauskas <[email protected]> Reviewed-by: Aric Cyr <[email protected]> Acked-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>