summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau
AgeCommit message (Collapse)AuthorFilesLines
2019-08-23drm/nouveau/kms/gv100-: use premultiplied alpha blending between planesBen Skeggs1-3/+3
This is apparently the assumed default behaviour when blend properties are absent. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/nv50-: enable modern color management propertiesIlia Mirkin1-0/+5
For GF119:GV100, we can enable DEGAMMA/CTM/GAMMA. For earlier GPUs, as there is no CTM, having both degamma and gamma is a bit pointless. Later GPUs currently lack an implementation. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/gf119-: add ctm property supportIlia Mirkin4-0/+89
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC). Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
2019-08-23drm/nouveau/kms/nv50-: remove overlay alpha formatsIlia Mirkin4-14/+0
The overlay logic can only do colorkey-based selection, not alpha-blending. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/fifo/gk104-: fix parsing of mmu fault dataBen Skeggs10-26/+67
Pascal was particularly incorrect, as the register changed to be more in the same format as the MMU fault buffers are. Shouldn't have impacted much more than confusing MMU fault log messages. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/fifo/gf1xx: convert to using nvkm_fault_dataBen Skeggs3-86/+106
Would like to be able to reuse gf100_fifo_intr_fault() for (some of) the later chipsets too, as it's identical. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/bios/init: handle INIT_RESET_END devinit opcodeRhys Kidd1-1/+12
Signal that the reset sequence has completed. This opcode signals that the software reset sequence has completed. Ordinarily, no actual operations are performed by the opcode. However it allows for possible software work arounds by devinit engines in software agents other than the VBIOS, such as the resman, FCODE, and EFI driver. Signed-off-by: Rhys Kidd <rhyskidd@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/bios/init: handle INIT_RESET_BEGUN devinit opcodeRhys Kidd1-1/+12
Signal that the reset sequence has begun. This opcode signals that the software reset sequence has begun. Ordinarily, no actual operations are performed by the opcode. However it allows for possible software work arounds by devinit engines in software agents other than the VBIOS, such as the resman, FCODE, and EFI driver. Signed-off-by: Rhys Kidd <rhyskidd@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/bios: downgrade absence of tmds table to info from an errorRhys Kidd1-1/+1
Absence of a TMDS Info Table is common on Optimus setups where the NVIDIA gpu is not connected directly to any outputs. Reporting an error in this scenario is too harsh. Accordingly, change the error message to an info message. By default the error message also causes a boot flicker for these sytems. Signed-off-by: Rhys Kidd <rhyskidd@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: Disable atomic support on a per-device basisVille Syrjälä1-1/+1
We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: nouveau@lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/nv50-: add fp16 scanout supportIlia Mirkin7-18/+66
Older hardware seems to want 0..1024 values, while new hardware takes 0..1 values. We set the gain to 1024 for the earlier display classes. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/nv50-: disable input lut harderBen Skeggs1-0/+2
Under some circumstances, it could be left enabled when it shouldn't be. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/tu102-: disable input lut when input is already FP16Ben Skeggs1-1/+3
On Turing, an input LUT is required to transform inputs in fixed-point formats to FP16 for the internal display pipe. We provide an identity mapping whenever a window is enabled for this reason. HW has error checks to ensure when the input is already FP16, that the input LUT is also disabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/kms/gv100: allow windows to use PACKED8BPP formatsBen Skeggs1-1/+1
Required for upcoming FP16 scanout support. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: fix nvif/device.h is included more than onceHariprasad Kelam1-1/+0
remove duplicate inclusion of nvif/device.h Issue identified by includecheck Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/dispnv04: subdev/bios.h is included more than onceHariprasad Kelam1-1/+0
remove duplicate inclusion of subdev/bios.h Issue identified by includecheck Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/mmu: use struct_size() helperGustavo A. R. Silva1-1/+1
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr; with: struct_size(kind, data, mmu->kind_nr) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: drop use of drmp.hSam Ravnborg23-28/+14
Drop use of the deprecated drmP.h file from drm/nouveau. Build tested using allyesconfig and allmodconfig. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: drop drmP.h from all header filesSam Ravnborg4-4/+3
Drop include of the deprecated drmP.h from all nouveau heder files. This allows us to remove drmP.h from all .c files without any side-effects in a follow-up commit. Build tested using allyeyconfig and allmodconfig Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: drop drmP.h from nouveau_drv.hSam Ravnborg5-1/+13
Drop the deprecated drmP.h header from nouveau_drv.h. Fix fallout in other parts of the driver. Build tested using allmodconfig and allyesconfig. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: drop use of DRM_UDELAYSam Ravnborg1-1/+1
The DRM_UDELAY is a simple wrapper for udealy() and to be consistent call udelay() direct like in may other places. This avoids the need to pull in drm_os_linux.h when we later drop drmP.h uses in nouveau. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/bios/init: fix spelling mistake "CONDITON" -> "CONDITION"Colin Ian King1-1/+1
There is a spelling mistake in a warning message. Fix it. Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau/secboot: Make acr_r352_ls_gpccs_func staticYueHaibing1-1/+1
Fix sparse warning: drivers/gpu/drm/nouveau/nvkm/subdev/secboot/acr_r352.c:1092:1: warning: symbol 'acr_r352_ls_gpccs_func' was not declared. Should it be static? Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-23drm/nouveau: Don't retry infinitely when receiving no data on i2c over AUXLyude Paul1-7/+17
While I had thought I had fixed this issue in: commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") It turns out that while I did fix the error messages I was seeing on my P50 when trying to access i2c busses with the GPU in runtime suspend, I accidentally had missed one important detail that was mentioned on the bug report this commit was supposed to fix: that the CPU would only lock up when trying to access i2c busses _on connected devices_ _while the GPU is not in runtime suspend_. Whoops. That definitely explains why I was not able to get my machine to hang with i2c bus interactions until now, as plugging my P50 into it's dock with an HDMI monitor connected allowed me to finally reproduce this locally. Now that I have managed to reproduce this issue properly, it looks like the problem is much simpler then it looks. It turns out that some connected devices, such as MST laptop docks, will actually ACK i2c reads even if no data was actually read: [ 275.063043] nouveau 0000:01:00.0: i2c: aux 000a: 1: 0000004c 1 [ 275.063447] nouveau 0000:01:00.0: i2c: aux 000a: 00 01101000 10040000 [ 275.063759] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000001 [ 275.064024] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000 [ 275.064285] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000 [ 275.064594] nouveau 0000:01:00.0: i2c: aux 000a: rd 00000000 Because we don't handle the situation of i2c ack without any data, we end up entering an infinite loop in nvkm_i2c_aux_i2c_xfer() since the value of cnt always remains at 0. This finally properly explains how this could result in a CPU hang like the ones observed in the aforementioned commit. So, fix this by retrying transactions if no data is written or received, and give up and fail the transaction if we continue to not write or receive any data after 32 retries. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-08-22Merge branch 'odp_fixes' into hmm.gitJason Gunthorpe1-9/+13
From rdma.git Jason Gunthorpe says: ==================== This is a collection of general cleanups for ODP to clarify some of the flows around umem creation and use of the interval tree. ==================== The branch is based on v5.3-rc5 due to dependencies, and is being taken into hmm.git due to dependencies in the next patches. * odp_fixes: RDMA/mlx5: Use odp instead of mr->umem in pagefault_mr RDMA/mlx5: Use ib_umem_start instead of umem.address RDMA/core: Make invalidate_range a device operation RDMA/odp: Use kvcalloc for the dma_list and page_list RDMA/odp: Check for overflow when computing the umem_odp end RDMA/odp: Provide ib_umem_odp_release() to undo the allocs RDMA/odp: Split creating a umem_odp from ib_umem_get RDMA/odp: Make the three ways to create a umem_odp clear RMDA/odp: Consolidate umem_odp initialization RDMA/odp: Make it clearer when a umem is an implicit ODP umem RDMA/odp: Iterate over the whole rbtree directly RDMA/odp: Use the common interval tree library instead of generic RDMA/mlx5: Fix MR npages calculation for IB_ACCESS_HUGETLB Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-21drm/nouveau: Initialize GEM object before TTM objectThierry Reding4-41/+77
TTM assumes that drivers initialize the embedded GEM object before calling the ttm_bo_init() function. This is not currently the case in the Nouveau driver. Fix this by splitting up nouveau_bo_new() into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can be initialized before TTM BO initialization when necessary. Fixes: b96f3e7c8069 ("drm/ttm: use gem vma_node") Acked-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo
2019-08-21Merge tag 'drm-misc-next-2019-08-19' of ↵Dave Airlie6-17/+17
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: Cross-subsystem Changes: Core Changes: - dma-buf: add reservation_object_fences helper, relax reservation_object_add_shared_fence, remove reservation_object seq number (and then restored) - dma-fence: Shrinkage of the dma_fence structure, Merge dma_fence_signal and dma_fence_signal_locked, Store the timestamp in struct dma_fence in a union with cb_list Driver Changes: - More dt-bindings YAML conversions - More removal of drmP.h includes - dw-hdmi: Support get_eld and various i2s improvements - gm12u320: Few fixes - meson: Global cleanup - panfrost: Few refactors, Support for GPU heap allocations - sun4i: Support for DDC enable GPIO - New panels: TI nspire, NEC NL8048HL11, LG Philips LB035Q02, Sharp LS037V7DW01, Sony ACX565AKM, Toppoly TD028TTEC1 Toppoly TD043MTEA1 Signed-off-by: Dave Airlie <airlied@redhat.com> [airlied: fixup dma_resv rename fallout] From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190819141923.7l2adietcr2pioct@flea
2019-08-20mm: remove CONFIG_MIGRATE_VMA_HELPERChristoph Hellwig1-1/+0
CONFIG_MIGRATE_VMA_HELPER guards helpers that are required for proper devic private memory support. Remove the option and just check for CONFIG_DEVICE_PRIVATE instead. Link: https://lore.kernel.org/r/20190814075928.23766-11-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20mm: remove the unused MIGRATE_PFN_DEVICE flagChristoph Hellwig1-2/+1
No one ever checks this flag, and we could easily get that information from the page if needed. Link: https://lore.kernel.org/r/20190814075928.23766-10-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: simplify nouveau_dmem_migrate_vmaChristoph Hellwig1-129/+55
Factor the main copy page to vram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_migrate structure for argument passing. As an added benefit the new version only allocates the dma address array once and reuses it for each subsequent chunk of work. Link: https://lore.kernel.org/r/20190814075928.23766-8-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: simplify nouveau_dmem_migrate_to_ramChristoph Hellwig1-121/+40
Factor the main copy page to ram routine out into a helper that acts on a single page and which doesn't require the nouveau_dmem_fault structure for argument passing. Also remove the loop over multiple pages as we only handle one at the moment, although the structure of the main worker function makes it relatively easy to add multi page support back if needed in the future. But at least for now this avoid the needed to dynamically allocate memory for the dma addresses in what is essentially the page fault path. Link: https://lore.kernel.org/r/20190814075928.23766-7-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: remove a few function stubsChristoph Hellwig1-11/+0
nouveau_dmem_migrate_vma and nouveau_dmem_convert_pfn are only called when CONFIG_DRM_NOUVEAU_SVM is enabled, so there is no need to provide !CONFIG_DRM_NOUVEAU_SVM stubs for them. Link: https://lore.kernel.org/r/20190814075928.23766-6-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: factor out dmem fence completionChristoph Hellwig1-18/+15
Factor out the end of fencing logic from the two migration routines. Link: https://lore.kernel.org/r/20190814075928.23766-5-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: factor out device memory address calculationChristoph Hellwig1-25/+17
Factor out the repeated device memory address calculation into a helper. Link: https://lore.kernel.org/r/20190814075928.23766-4-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20nouveau: reset dma_nr in nouveau_dmem_migrate_alloc_and_copyChristoph Hellwig1-0/+1
When we start a new batch of dma_map operations we need to reset dma_nr, as we start filling a newly allocated array. Link: https://lore.kernel.org/r/20190814075928.23766-3-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20mm: turn migrate_vma upside downChristoph Hellwig1-59/+63
There isn't any good reason to pass callbacks to migrate_vma. Instead we can just export the three steps done by this function to drivers and let them sequence the operation without callbacks. This removes a lot of boilerplate code as-is, and will allow the drivers to drastically improve code flow and error handling further on. Link: https://lore.kernel.org/r/20190814075928.23766-2-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-20hmm: use mmu_notifier_get/put for 'struct hmm'Jason Gunthorpe1-0/+3
This is a significant simplification, it eliminates all the remaining 'hmm' stuff in mm_struct, eliminates krefing along the critical notifier paths, and takes away all the ugly locking and abuse of page_table_lock. mmu_notifier_get() provides the single struct hmm per struct mm which eliminates mm->hmm. It also directly guarantees that no mmu_notifier op callback is callable while concurrent free is possible, this eliminates all the krefs inside the mmu_notifier callbacks. The remaining krefs in the range code were overly cautious, drivers are already not permitted to free the mirror while a range exists. Link: https://lore.kernel.org/r/20190806231548.25242-6-jgg@ziepe.ca Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-15drm/nouveau: Only recalculate PBN/VCPI on mode/connector changesLyude Paul1-9/+13
I -thought- I had fixed this entirely, but it looks like that I didn't test this thoroughly enough as we apparently still make one big mistake with nv50_msto_atomic_check() - we don't handle the following scenario: * CRTC #1 has n VCPI allocated to it, is attached to connector DP-4 which is attached to encoder #1. enabled=y active=n * CRTC #1 is changed from DP-4 to DP-5, causing: * DP-4 crtc=#1→NULL (VCPI n→0) * DP-5 crtc=NULL→#1 * CRTC #1 steals encoder #1 back from DP-4 and gives it to DP-5 * CRTC #1 maintains the same mode as before, just with a different connector * mode_changed=n connectors_changed=y (we _SHOULD_ do VCPI 0→n here, but don't) Once the above scenario is repeated once, we'll attempt freeing VCPI from the connector that we didn't allocate due to the connectors changing, but the mode staying the same. Sigh. Since nv50_msto_atomic_check() has broken a few times now, let's rethink things a bit to be more careful: limit both VCPI/PBN allocations to mode_changed || connectors_changed, since neither VCPI or PBN should ever need to change outside of routing and mode changes. Changes since v1: * Fix accidental reversal of clock and bpp arguments in drm_dp_calc_pbn_mode() - William Lewis Signed-off-by: Lyude Paul <lyude@redhat.com> Reported-by: Bohdan Milar <bmilar@redhat.com> Tested-by: Bohdan Milar <bmilar@redhat.com> Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") References: 412e85b60531 ("drm/nouveau: Only release VCPI slots on mode changes") Cc: Lyude Paul <lyude@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Airlie <airlied@redhat.com> Cc: Jerry Zuo <Jerry.Zuo@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Juston Li <juston.li@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Karol Herbst <karolherbst@gmail.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: <stable@vger.kernel.org> # v5.1+ Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190809005307.18391-1-lyude@redhat.com
2019-08-13dma-buf: rename reservation_object to dma_resvChristian König6-17/+17
Be more consistent with the naming of the other DMA-buf objects. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/323401/
2019-08-09Merge tag 'drm-misc-next-2019-08-08' of ↵Dave Airlie12-66/+45
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 5.4: UAPI Changes: - HDCP: Add a Content protection type property Cross-subsystem Changes: Core Changes: - Continue to rework the include dependencies - fb: Remove the unused drm_gem_fbdev_fb_create function - drm-dp-helper: Make the link rate calculation more tolerant to non-explicitly defined, yet supported, rates - fb-helper: Map DRM client buffer only when required, and instanciate a shadow buffer when the device has a dirty function or says so - connector: Add a helper to link the DDC adapter used by that connector to the userspace - vblank: Switch from DRM_WAIT_ON to wait_event_interruptible_timeout - dma-buf: Fix a stack corruption - ttm: Embed a drm_gem_object struct to make ttm_buffer_object a superclass of GEM, and convert drivers to use it. - hdcp: Improvements to report the content protection type to the userspace Driver Changes: - Remove drm_gem_prime_import/export from being defined in the drivers - Drop DRM_AUTH usage from drivers - Continue to drop drmP.h - Convert drivers to the connector ddc helper - ingenic: Add support for more panel-related cases - komeda: Support for dual-link - lima: Reduce logging - mpag200: Fix the cursor support - panfrost: Export GPU features register to userspace through an ioctl - pl111: Remove the CLD pads wiring support from the DT - rockchip: Rework to use DRM PSR helpers, fix a bug in the VOP_WIN_GET macro - sun4i: Improve support for color encoding and range - tinydrm: Rework SPI support, improve MIPI-DBI support, move to drm/tiny - vkms: Rework of the CRC tracking - bridges: - sii902x: Add support for audio graph card - tc358767: Rework AUX data handling code - ti-sn65dsi86: Add Debugfs and proper DSI mode flags support - panels - Support for GiantPlus GPM940B0, Sharp LQ070Y3DG3B, Ortustech COM37H3M, Novatek NT39016, Sharp LS020B1DD01D, Raydium RM67191, Boe Himax8279d, Sharp LD-D5116Z01B - Conversion of the device tree bindings to the YAML description - jh057n00900: Rework the enable / disable path - fbdev: - ssd1307fb: Support more devices based on that controller Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190808121423.xzpedzkpyecvsiy4@flea
2019-08-07mm/hmm: make HMM_MIRROR an implicit optionChristoph Hellwig1-1/+3
Make HMM_MIRROR an option that is selected by drivers wanting to use it instead of a user visible option as it is just a low-level implementation detail. Link: https://lore.kernel.org/r/20190806160554.14046-15-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-07mm/hmm: remove the page_shift member from struct hmm_rangeChristoph Hellwig1-1/+0
All users pass PAGE_SIZE here, and if we wanted to support single entries for huge pages we should really just add a HMM_FAULT_HUGEPAGE flag instead that uses the huge page size instead of having the caller calculate that size once, just for the hmm code to verify it. Link: https://lore.kernel.org/r/20190806160554.14046-8-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-07mm/hmm: remove superfluous arguments from hmm_range_registerChristoph Hellwig1-3/+2
The start, end and page_shift values are all saved in the range structure, so we might as well use that for argument passing. Link: https://lore.kernel.org/r/20190806160554.14046-7-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-07nouveau: pass struct nouveau_svmm to nouveau_range_faultChristoph Hellwig1-6/+6
We'll need the nouveau_svmm structure to improve the function soon. For now this allows using the svmm->mm reference to unlock the mmap_sem, and thus the same dereference chain that the caller uses to lock and unlock it. Link: https://lore.kernel.org/r/20190806160554.14046-4-hch@lst.de Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
2019-08-07drm/nouveau: remove open-coded drm_invalid_op()Emil Velikov3-8/+1
Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190522150219.13913-2-emil.l.velikov@gmail.com
2019-08-07Revert "drm/nouveau: remove open-coded drm_invalid_op()"Sean Paul3-1/+8
This reverts commit ccdae42575695ab442941310bd67c7ed1714e273. Mandatory review was missing from this patch. Acked-by: Maxime Ripard <maxime.ripard@bootlin.com> Acked-by: Emil Velikov <emil.velikov@collabora.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190807142101.251400-6-sean@poorly.run
2019-08-06drm/nouveau: switch driver from bo->resv to bo->base.resvGerd Hoffmann4-6/+5
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-15-kraxel@redhat.com
2019-08-06drm/ttm: use gem vma_nodeGerd Hoffmann2-2/+2
Drop vma_node from ttm_buffer_object, use the gem struct (base.vma_node) instead. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-9-kraxel@redhat.com
2019-08-06drm/nouveau: use embedded gem objectGerd Hoffmann7-24/+20
Drop drm_gem_object from nouveau_bo, use the ttm_buffer_object.base instead. Build tested only. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-7-kraxel@redhat.com
2019-08-05dma-buf: add more reservation object locking wrappersChristian König1-2/+2
Complete the abstraction of the ww_mutex inside the reservation object. This allows us to add more handling and debugging to the reservation object in the future. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/320761/
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-24 15:43:07 +0300