- 23 Aug, 2019 21 commits
-
-
Ilia Mirkin authored
This adds support on GF119:GV100 (exclusive) for CTM (aka CSC). Signed-off-by:Ilia Mirkin <imirkin@alum.mit.edu>
-
Ilia Mirkin authored
The overlay logic can only do colorkey-based selection, not alpha-blending. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
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 authored
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: -
Rhys Kidd authored
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:
-
Rhys Kidd authored
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 authored
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:
-
Ville Syrjälä authored
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ilia Mirkin authored
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:
-
Ben Skeggs authored
Under some circumstances, it could be left enabled when it shouldn't be. Signed-off-by: -
Ben Skeggs authored
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 authored
Required for upcoming FP16 scanout support. Signed-off-by: -
Hariprasad Kelam authored
remove duplicate inclusion of nvif/device.h Issue identified by includecheck Signed-off-by:
Hariprasad Kelam <hariprasad.kelam@gmail.com> Signed-off-by:
-
Hariprasad Kelam authored
remove duplicate inclusion of subdev/bios.h Issue identified by includecheck Signed-off-by:
-
Gustavo A. R. Silva authored
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:
-
Sam Ravnborg authored
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:
-
Sam Ravnborg authored
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 authored
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 authored
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:
-
Colin Ian King authored
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:
-
YueHaibing authored
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:
-
- 22 Aug, 2019 2 commits
-
-
https://git.pengutronix.de/git/lst/linuxDave Airlie authored
Most importantly per-process address spaces on GPUs that are capable of providing proper isolation has finished baking. This is the base for our softpin implementation, which allows us to support the texture descriptor buffers used by GC7000 series GPUs without a major UAPI extension/rework. Shortlog of notable changes: - code cleanup from Fabio - fix performance counters on GC880 and GC2000 GPUs from Christian - drmP.h header removal from Sam - per process address space support on MMUv2 GPUs from me - softpin support from me Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/1565946875.2641.73.camel@pengutronix.de
-
git://linuxtv.org/pinchartl/mediaDave Airlie authored
- R-Car DU fixes - Misc. DRM cleanups Signed-off-by:
-
- 21 Aug, 2019 1 commit
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
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:
-
- 19 Aug, 2019 1 commit
-
-
Nishka Dasgupta authored
Static structure fb_funcs, of type drm_framebuffer_funcs, is used only when it is passed to drm_gem_fb_create_with_funcs() as its last argument. drm_gem_fb_create_with_funcs does not modify its lst argument (fb_funcs) and hence fb_funcs is never modified. Therefore make fb_funcs constant to protect it from further modification. Issue found with Coccinelle. Signed-off-by:
Nishka Dasgupta <nishkadg.linux@gmail.com> Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by:
-
- 18 Aug, 2019 1 commit
-
-
Nishka Dasgupta authored
The static structure vbox_fb_helper_funcs, of type drm_fb_helper_funcs, is used only when it is passed as the third argument to drm_fb_helper_fbdev_setup(), which does not modify it. Hence make it constant to protect it from unintended modifications. Issue found with Coccinelle. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 17 Aug, 2019 5 commits
-
-
Chris Wilson authored
The timestamp and the cb_list are mutually exclusive, the cb_list can only be added to prior to being signaled (and once signaled we drain), while the timestamp is only valid upon being signaled. Both the timestamp and the cb_list are only valid while the fence is alive, and as soon as no references are held can be replaced by the rcu_head. By reusing the union for the timestamp, we squeeze the base dma_fence struct to 64 bytes on x86-64. v2: Sort the union chronologically Suggested-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by: Christian König <christian.koenig@amd.com>. Link: https://patchwork.freedesktop.org/patch/msgid/20190817153022.5749-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Currently dma_fence_signal() tries to avoid the spinlock and only takes it if absolutely required to walk the callback list. However, to allow for some users to surreptitiously insert lazy signal callbacks that do not depend on enabling the signaling mechanism around every fence, we always need to notify the callbacks on signaling. As such, we will always need to take the spinlock and dma_fence_signal() effectively becomes a clone of dma_fence_signal_locked(). v2: Update the test_and_set_bit() before entering the spinlock. v3: Drop the test_[and_set]_bit() before the spinlock, it's a caller error so expected to be very unlikely. Signed-off-by:
-
Chris Wilson authored
Before we notify the fence signal callback, we remove the cb from the list. However, since we are processing the entire list from underneath the spinlock, we do not need to individual delete each element, but can simply reset the link and the entire list. Signed-off-by:
-
Chris Wilson authored
Rearrange the couple of 32-bit atomics hidden amongst the field of pointers that unnecessarily caused the compiler to insert some padding, shrinks the size of the base struct dma_fence from 80 to 72 bytes on x86-64. Signed-off-by:
-
Colin Ian King authored
Variable val is initialized to a value in a for-loop that is never read and hence it is redundant. Remove it. Addresses-Coverity: ("Unused value") Signed-off-by:
-
- 16 Aug, 2019 7 commits
-
-
Laurent Pinchart authored
drm_panel-based drivers for the ACX565AKM, LB035Q02, LS037V7DW01, NL8048HL11, TD028TTEC1 and TD043MTEA1 are available, remove the omapdrm-specific drivers. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Laurent Pinchart authored
Standard DRM panel drivers for several panels used by omapfb2 are now available. Their module name clashes with the modules from drivers/video/fbdev/omap2/omapfb/displays, part of the deprecated omapfb2 fbdev driver. As omapfb2 can only be compiled when the omapdrm driver is disabled, and the DRM panel drivers are useless in that case, make the omapfb2 panels depend on the standard DRM panels being disabled to fix the name clash. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: dc2e1e5b ("drm/panel: Add driver for the Toppoly TD043MTEA1 panel") Fixes: 415b8dd0 ("drm/panel: Add driver for the Toppoly TD028TTEC1 panel") Fixes: 1c8fc3f0 ("drm/panel: Add driver for the Sony ACX565AKM panel") Fixes: c9cf4c2a ("drm/panel: Add driver for the Sharp LS037V7DW01 panel") Fixes: df439abe ("drm/panel: Add driver for the NEC NL8048HL11 panel") Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> [added tags] Link: https://patchwork.freedesktop.org/patch/msgid/20190816122228.9475-2-laurent.pinchart@ideasonboard.com
-
Fabrizio Castro authored
Using name "bridge" for macro bridge_to_rcar_lvds argument doesn't work when the pointer name used by the caller is not "bridge". Rename the argument to "b" to allow for any pointer name. While at it, fix the connector_to_rcar_lvds macro similarly. Fixes: c6a27fa4 ("drm: rcar-du: Convert LVDS encoder code to bridge driver") Signed-off-by:
Fabrizio Castro <fabrizio.castro@bp.renesas.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> [Fix connector_to_rcar_lvds] Signed-off-by:
-
Laurent Pinchart authored
DRM bridges are only used by atomic drivers, and none of them use the legacy helpers. Drop bridge support from those helpers to prepare for making the bridge operations atomic-aware. Signed-off-by:
Sean Paul <seanpaul@chromium.org> Acked-by:
-
Laurent Pinchart authored
The dw-hdmi, kirin and imx drivers include the drm/drm_encoder_slave.h header but don't use the encoder slave API. Remove it or replace it with drm/drm_encoder.h as needed. Signed-off-by:
-
Chris Wilson authored
This reverts 67c97fb7 ("dma-buf: add reservation_object_fences helper") dd7a7d1f ("drm/i915: use new reservation_object_fences helper") 0e1d8083 ("dma-buf: further relax reservation_object_add_shared_fence") 5d344f58 ("dma-buf: nuke reservation_object seq number") The scenario that defeats simply grabbing a set of shared/exclusive fences and using them blissfully under RCU is that any of those fences may be reallocated by a SLAB_TYPESAFE_BY_RCU fence slab cache. In this scenario, while keeping the rcu_read_lock we need to establish that no fence was changed in the dma_resv after a read (or full) memory barrier. Signed-off-by:
-
git://people.freedesktop.org/~thomash/linuxDave Airlie authored
A couple of independent patches extracted from the 5.3 pull request, fixed for merge conflicts and a single unused variable warning. And the drmP.h removal from Sam. Signed-off-by:
-
- 15 Aug, 2019 2 commits
-
-
Lucas Stach authored
With softpin we allow the userspace to take control over the GPU virtual address space. The new capability is relected by a bump of the minor DRM version. There are a few restrictions for userspace to take into account: 1. The kernel reserves a bit of the address space to implement zero page faulting and mapping of the kernel internal ring buffer. Userspace can query the kernel for the first usable GPU VM address via ETNAVIV_PARAM_SOFTPIN_START_ADDR. 2. We only allow softpin on GPUs, which implement proper process separation via PPAS. If softpin is not available the softpin start address will be set to ~0. 3. Softpin is all or nothing. A submit using softpin must not use any address fixups via relocs. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
Guido Günther <agx@sigxcpu.org>
-
Lucas Stach authored
Allow the mapping code to request a specific virtual address for the gem mapping. If the virtual address is zero we fall back to the old mode of allocating a virtual address for the mapping. Signed-off-by:
-
