summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/nouveau/include
AgeCommit message (Collapse)AuthorFilesLines
2019-06-11drm/nouveau/i2c: Disable i2c bus access after ->fini()Lyude Paul1-0/+2
commit 342406e4fbba9a174125fbfe6aeac3d64ef90f76 upstream. For a while, we've had the problem of i2c bus access not grabbing a runtime PM ref when it's being used in userspace by i2c-dev, resulting in nouveau spamming the kernel log with errors if anything attempts to access the i2c bus while the GPU is in runtime suspend. An example: [ 130.078386] nouveau 0000:01:00.0: i2c: aux 000d: begin idle timeout ffffffff Since the GPU is in runtime suspend, the MMIO region that the i2c bus is on isn't accessible. On x86, the standard behavior for accessing an unavailable MMIO region is to just return ~0. Except, that turned out to be a lie. While computers with a clean concious will return ~0 in this scenario, some machines will actually completely hang a CPU on certian bad MMIO accesses. This was witnessed with someone's Lenovo ThinkPad P50, where sensors-detect attempting to access the i2c bus while the GPU was suspended would result in a CPU hang: CPU: 5 PID: 12438 Comm: sensors-detect Not tainted 5.0.0-0.rc4.git3.1.fc30.x86_64 #1 Hardware name: LENOVO 20EQS64N17/20EQS64N17, BIOS N1EET74W (1.47 ) 11/21/2017 RIP: 0010:ioread32+0x2b/0x30 Code: 81 ff ff ff 03 00 77 20 48 81 ff 00 00 01 00 76 05 0f b7 d7 ed c3 48 c7 c6 e1 0c 36 96 e8 2d ff ff ff b8 ff ff ff ff c3 8b 07 <c3> 0f 1f 40 00 49 89 f0 48 81 fe ff ff 03 00 76 04 40 88 3e c3 48 RSP: 0018:ffffaac3c5007b48 EFLAGS: 00000292 ORIG_RAX: ffffffffffffff13 RAX: 0000000001111000 RBX: 0000000001111000 RCX: 0000043017a97186 RDX: 0000000000000aaa RSI: 0000000000000005 RDI: ffffaac3c400e4e4 RBP: ffff9e6443902c00 R08: ffffaac3c400e4e4 R09: ffffaac3c5007be7 R10: 0000000000000004 R11: 0000000000000001 R12: ffff9e6445dd0000 R13: 000000000000e4e4 R14: 00000000000003c4 R15: 0000000000000000 FS: 00007f253155a740(0000) GS:ffff9e644f600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005630d1500358 CR3: 0000000417c44006 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: g94_i2c_aux_xfer+0x326/0x850 [nouveau] nvkm_i2c_aux_i2c_xfer+0x9e/0x140 [nouveau] __i2c_transfer+0x14b/0x620 i2c_smbus_xfer_emulated+0x159/0x680 ? _raw_spin_unlock_irqrestore+0x1/0x60 ? rt_mutex_slowlock.constprop.0+0x13d/0x1e0 ? __lock_is_held+0x59/0xa0 __i2c_smbus_xfer+0x138/0x5a0 i2c_smbus_xfer+0x4f/0x80 i2cdev_ioctl_smbus+0x162/0x2d0 [i2c_dev] i2cdev_ioctl+0x1db/0x2c0 [i2c_dev] do_vfs_ioctl+0x408/0x750 ksys_ioctl+0x5e/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x60/0x1e0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f25317f546b Code: 0f 1e fa 48 8b 05 1d da 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed d9 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffc88caab68 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00005630d0fe7260 RCX: 00007f25317f546b RDX: 00005630d1598e80 RSI: 0000000000000720 RDI: 0000000000000003 RBP: 00005630d155b968 R08: 0000000000000001 R09: 00005630d15a1da0 R10: 0000000000000070 R11: 0000000000000246 R12: 00005630d1598e80 R13: 00005630d12f3d28 R14: 0000000000000720 R15: 00005630d12f3ce0 watchdog: BUG: soft lockup - CPU#5 stuck for 23s! [sensors-detect:12438] Yikes! While I wanted to try to make it so that accessing an i2c bus on nouveau would wake up the GPU as needed, airlied pointed out that pretty much any usecase for userspace accessing an i2c bus on a GPU (mainly for the DDC brightness control that some displays have) is going to only be useful while there's at least one display enabled on the GPU anyway, and the GPU never sleeps while there's displays running. Since teaching the i2c bus to wake up the GPU on userspace accesses is a good deal more difficult than it might seem, mostly due to the fact that we have to use the i2c bus during runtime resume of the GPU, we instead opt for the easiest solution: don't let userspace access i2c busses on the GPU at all while it's in runtime suspend. Changes since v1: * Also disable i2c busses that run over DP AUX Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-14drm/nouveau/tmr: fully separate alarm execution/pending listsBen Skeggs1-0/+1
commit b4e382ca7586a63b6c1e5221ce0863ff867c2df6 upstream. Reusing the list_head for both is a bad idea. Callback execution is done with the lock dropped so that alarms can be rescheduled from the callback, which means that with some unfortunate timing, lists can get corrupted. The execution list should not require its own locking, the single function that uses it can only be called from a single context. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-09-22drm/nouveau: Revert "bus: remove cpu_coherent flag"Karol Herbst1-0/+1
This reverts commit aff51175cdbf345740ec9203eff88e772af88059. The commit caused fence timeouts within nvc0_screen_destroy and most likely other places as well. The most obvious effect is, that userspace processes take minutes to actually quit. Signed-off-by: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bus: remove cpu_coherent flagAlexandre Courbot1-1/+0
This flag's only remaining function is to ignore the uncached flag for BOs on coherent architectures. However the reason for allocating an object uncache on a non-coherent architecture (namely because the cost of doing explicit flushes/ invalidations is higher than the benefit of caching the data because accesses are few and far between) should also apply on architectures for which coherency is maintained implicitly. Thus allocate coherent objects as uncached on all architectures. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ce/gp104: initial supportBen Skeggs2-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp104: initial supportBen Skeggs2-0/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/gr/gp100: initial supportBen Skeggs2-0/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ce/gp100: initial supportBen Skeggs2-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fifo/gp100: initial supportBen Skeggs2-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp100: initial supportBen Skeggs2-0/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/ltc/gp100: initial supportBen Skeggs1-0/+1
Due to the GPU preventing us from touching NV_PLTCG_LTCS_LTSS_CBC_BASE, we cannot provide CBC/ZBC support without signed PMU firmware to handle the task for us... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/pci/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/core: recognise GP100 chipsetBen Skeggs2-0/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/core: increase maximum nvenc instances to 3Ben Skeggs1-3/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/core: increase maximum ce instances to 6Ben Skeggs1-3/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/fb/gf100-: allow selection of an alternate big page sizeBen Skeggs1-0/+2
GFxxx/GM1xx support the selection of 64/128KiB big pages globally. GM2xx supports the same, as well as another mode where the page size can be selected per-instance. We default to 128KiB pages (With per-instance for GM200, but the current code selects 128KiB there already) as the MMU code isn't currently able to handle otherwise. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios: pointers beyond end of first image need special handlingBen Skeggs1-0/+3
Makes common the code that was previously used by the PMU table parsing, as it appears other tables need this too. Not much of an idea what this is all about... Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/bios: guard against out-of-bounds accesses to imageBen Skeggs1-4/+3
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/volt: save the voltage range we are able to setKarol Herbst1-0/+3
We shouldn't set voltages below the min or above the max voltage the gpu is able to set, so save the range for future lookups. Signed-off-by: Karol Herbst <karolherbst@gmail.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Tested-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/tegra: fetch gpu_speedo_idAlexandre Courbot1-0/+1
The GPU speedo ID is required to select the right clk/volt parameters on GM20B. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/secboot: use nvkm_mc_enable/disable()Ben Skeggs1-1/+0
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/secboot: use nvkm_mc_intr_mask/unmask()Ben Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc: support for temporarily masking interrupts from a specific ↵Ben Skeggs1-0/+1
device Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc: expose device enable/disable separately, as well as resetBen Skeggs1-1/+3
There are cases where subdevs need to perform additonal actions around the master reset, so we want to expost the operations separately. This commit also adds a flag to the NV_PMC_ENABLE bitfield definitions which allow skipping the automatic reset() called from core/subdev.c. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/mc: take nvkm_device as argument to public functionsBen Skeggs1-5/+5
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/top: add function to lookup interrupt mask for a given deviceBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/top: take nvkm_device as argument to public functionsBen Skeggs1-4/+4
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-06-02drm/nouveau/core: swap the order of imem/fbBen Skeggs1-1/+1
Fixes a use-after-free reported by valgrind and KASAN. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-06-02drm/nouveau/bios/disp: fix handling of "match any protocol" entriesBen Skeggs1-2/+3
As it turns out, a value of 0xff means "any protocol" and not "VGA". Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-05-20drm/nouveau/fb/gm200: setup mmu debug buffer registers at init()Ben Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/fb/gf100-: allocate mmu debug buffersBen Skeggs1-0/+3
Later chipsets require setting this up both in FB and GR, so let's just move the allocation to FB. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/core: remove pmc_enable argument from subdev ctorBen Skeggs4-8/+3
These are now specified directly in the MC subdev. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc/nv11: define reset masks + intr cleanupBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc/nv17: define reset masks + intr cleanupBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc/g84: define reset masks + intr cleanupBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc/gt215: define reset masks + intr cleanupBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc/gk104: define reset masks + intr cleanupBen Skeggs1-0/+1
Engine fields have been removed, as they're specified by PTOP. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/mc: add helper function to handle device resetBen Skeggs1-0/+1
This will be later extended to handle PTOP-specified reset masks as well as the hardcoded ones. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/top/gk104: initial implementationBen Skeggs1-0/+2
Ported from the code currently in engine/fifo/gk104.c. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/top: initial implementationBen Skeggs1-0/+7
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/core: add top plumbingBen Skeggs2-0/+11
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/iccsense: split sensor into own structKarol Herbst1-0/+1
v2: add list_del call, reword error message Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/iccsense: convert to linked listKarol Herbst1-3/+1
v2: add list_del calls Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/iccsense: remove read functionKarol Herbst1-1/+0
Signed-off-by: Karol Herbst <nouveau@karolherbst.de> Reviewed-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-05-20drm/nouveau/devinit/gf100: make devinit on resume saferAlexandre Courbot1-0/+1
In case of successful suspend, devinit will have to be run and this is the behavior currently hardcoded. However, as FD bug 94725 suggests, there might be cases where runtime suspend leaves the GPU powered, and in such cases devinit should not be run on resume. On GF100+ we have a reliable way to know whether we need to run devinit. Use it instead of blindly trusting the flag set by nvkm_devinit_fini(). The code around the NvForcePost also needs to be slightly reworked in order to keep working. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Suggested-by: Dave Airlie <airlied@redhat.com> Suggested-by: Karol Herbst <nouveau@karolherbst.de> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-04-06drm/nouveau/tegra: acquire and enable reference clock if neededAlexandre Courbot1-0/+5
GM20B requires an extra clock compared to GK20A. Add that information into the platform data and acquire and enable this clock if necessary. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14drm/nouveau/clk/gm20b: add basic driverAlexandre Courbot1-0/+1
Add a basic clock driver that reuses the GK20A logic. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>