summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/include
AgeCommit message (Collapse)AuthorFilesLines
2021-03-04drm/nouveau/kms: handle mDP connectorsKarol Herbst1-0/+1
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream. In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by: Mark Pearson <markpearson@lenovo.com> Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-02-13drm/nouveau/nvif: fix method count when pushing an arrayBen Skeggs1-108/+108
[ Upstream commit d502297008142645edf5c791af424ed321e5da84 ] Reported-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-04drm/nouveau/kms/gk104-gp1xx: Fix > 64x64 cursorsLyude Paul1-0/+4
commit ba839b7598440a5d78550a115bac21b08d57cc32 upstream. While we do handle the additional cursor sizes introduced in NVE4, it looks like we accidentally broke this when converting over to use Nvidia's display headers. Since we now use NVVAL in dispnv50/head907d.c in order to format the value for the cursor layout and NVD9 only had one byte reserved vs. the 2 bytes reserved in later generations, we end up accidentally stripping the second bit in the cursor layout format parameter - causing us to set the wrong cursor size. This fixes that by adding our own curs_set hook for 917d which uses the NV917D headers. Cc: Martin Peres <martin.peres@free.fr> Cc: Jeremy Cline <jcline@redhat.com> Cc: Simon Ser <contact@emersion.fr> Cc: <stable@vger.kernel.org> # v5.9+ Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: ed0b86a90bf9 ("drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_curs_set()") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-30drm/nouveau/kms/nv50-: Program notifier offset before requesting disp capsLyude Paul2-1/+8
Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier offset programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix this by doing that, and also perform an update afterwards to prevent racing with the GPU when reading capabilities. v2: * Don't just program the DMA notifier offset, make sure to actually perform an update v3: * Don't call UPDATE() * Actually read the correct notifier fields, as apparently the CAPABILITIES_DONE field lives in a different location than the main NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different CAPABILITIES_DONE field then pre-907d cards. v4: * Don't forget to check the return value of core507d_read_caps() v5: * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY * Disable notifier after calling GetCapabilities() Signed-off-by: Lyude Paul <lyude@redhat.com> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support") Cc: <stable@vger.kernel.org> # v5.8+ Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-09-03drm/nouveau/kms/nv50-: add some whitespace before debug messageBen Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/fence: use NVIDIA's headers for sync()Ben Skeggs1-0/+10
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/fence: use NVIDIA's headers for emit()Ben Skeggs2-0/+69
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/bo: use NVIDIA's headers for move move()Ben Skeggs1-0/+162
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/bo: use NVIDIA's headers for move init()Ben Skeggs3-0/+272
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/fbcon/nv50-: use NVIDIA's headers for accel_init()Ben Skeggs2-0/+694
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for core head_olut_set()Ben Skeggs1-0/+106
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for core or_ctrl()Ben Skeggs4-0/+702
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for core init()Ben Skeggs3-0/+1225
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wndw image_set()Ben Skeggs3-0/+252
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wndw csc_set()Ben Skeggs2-0/+285
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wndw ntfy_reset()Ben Skeggs1-0/+88
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wndw sema_set()Ben Skeggs1-0/+394
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wimm point()Ben Skeggs1-0/+31
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: use NVIDIA's headers for wimm space()Ben Skeggs1-0/+36
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/fbcon: convert accel_init() to new push macrosBen Skeggs6-0/+289
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: implement proper push buffer control logicBen Skeggs1-0/+13
We had a, what was supposed to be temporary, hack in the KMS code where we'd completely drain an EVO/NVD channel's push buffer when wrapping to the start again, instead of treating it as a ring buffer. Let's fix that, finally. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: convert wndw sema_set() to new push macrosBen Skeggs2-0/+190
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: convert wimm point() to new push macrosBen Skeggs2-0/+67
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/kms/nv50-: wrap existing command submission in nvif_push interfaceBen Skeggs2-0/+567
This commit pulls in a bunch of new push buffer macros which are able to support NVIDIA's class headers, and provide more useful debug output and error checking (compile-time, where possible) than we had previously. Will incrementally transition each function over to the unified interfaces. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: add support for object-level debug outputBen Skeggs3-0/+46
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every notify object a human-readable nameBen Skeggs1-4/+5
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every disp object a human-readable identifierBen Skeggs1-1/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every usermode object a human-readable identifierBen Skeggs1-2/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every vmm object a human-readable identifierBen Skeggs1-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every mem object a human-readable identifierBen Skeggs1-6/+8
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every mmu object a human-readable identifierBen Skeggs1-2/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every device object a human-readable identifierBen Skeggs1-3/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: give every object a human-readable identifierBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/nvif: rename client ctor/dtorBen Skeggs1-2/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com>
2020-07-24drm/nouveau/pmu/gm20x: don't pretend we support loading with our custom FWBen Skeggs1-1/+1
It technically loads, and runs, but is ultimately pointless outside of a very narrow window (fanless systems where one wants to attempt using the, broken for a lot of gm20x, memory reclocking code). It's also potentially dangerous to override the VBIOS-provided "Pre-OS" PMU, which would be responsible for fan control otherwise. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/acr: store a mask of LS falcons the controlling LSFW can bootstrapBen Skeggs1-0/+3
This will prevent some pain with broken firmware trees, as under some circumstances the HSFW can fail and leave the GPU in a state we don't know how to recover from. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/core: drop error message when no compatible FW foundBen Skeggs1-4/+1
This is less than useful with some subdevs having _nofw variants in their FWIF lists - it's cleaner to handle them all in the same way. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/nvfw: firmware structures should begin with nvfw_Timur Tabi3-11/+11
Rename all structures that are used directly by firmware to have a nvfw_ prefix. This makes it easier to identify structures that have a fixed, specific layout. A future patch will define several more such structures, so it's important to be consistent now. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-07-24drm/nouveau/tmr: fix nvkm_usec/nvkm_msec definitionsTimur Tabi1-2/+2
nvkm_timer_wait_init() takes a u64 as a duration parameter, but the expression "(m) * 1000" will be promoted only to a 32-bit integer, if 'm' is also an integer. Changing the 1000 to 1000ULL ensures that the expression will be 64 bits. This change currently has no effect as there are no callers of nvkm_msec() that exceed 2000ms. Signed-off-by: Timur Tabi <ttabi@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-06-04drm/nouveau/disp: provide hint to OR allocation about HDA requirementsBen Skeggs1-1/+2
Will be used by a subsequent commit to influence SOR allocation policy. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-05-22drm/nouveau/disp/gv100-: expose capabilities classBen Skeggs1-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-05-22drm/nouveau/core: add nvkm_subdev_new_() for bare subdevsBen Skeggs1-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/nvif: protect waits against GPU falling off the busBen Skeggs2-21/+35
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-04-07drm/nouveau/nvif: access PTIMER through usermode class, if availableBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/gr/tu10x: initial supportBen Skeggs2-0/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/acr/tu10x: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/core: remove previous versioned fw loaderBen Skeggs1-4/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/secboot: removeBen Skeggs2-31/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/acr: implement new subdev to replace "secure boot"Ben Skeggs3-1/+281
ACR is responsible for managing the firmware for LS (Low Secure) falcons, this was previously handled in the driver by SECBOOT. This rewrite started from some test code that attempted to replicate the procedure RM uses in order to debug early Turing ACR firmwares that were provided by NVIDIA for development. Compared with SECBOOT, the code is structured into more individual steps, with the aim of making the process easier to follow/debug, whilst making it possible to support newer firmware versions that may have a different binary format or API interface. The HS (High Secure) binary(s) are now booted earlier in device init, to match the behaviour of RM, whereas SECBOOT would delay this until we try to boot the first LS falcon. There's also additional debugging features available, with the intention of making it easier to solve issues during FW/HW bring-up in the future. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2020-01-15drm/nouveau/fb/gp102-: unlock VPR as part of FB initBen Skeggs2-0/+33
We perform memory allocations long before we hit the code in SECBOOT that would unlock the VPR, which could potentially result in memory allocation within the locked region. Run the scrubber binary right after VRAM init to ensure we don't. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-21 20:47:28 +0300