summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/include/nvkm
Commit message (Collapse)AuthorAgeFilesLines
* drm/nouveau/core: support versioned firmware loadingBen Skeggs2019-06-071-2/+5
| | | | | | | We have a need for this now with updated SEC2 LS FW images that have an incompatible interface from the previous version. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: pass subdev into nvkm_firmware_get, rather than deviceBen Skeggs2019-06-071-5/+2Star
| | | | | | | It'd be nice to have FW loading debug messages to appear for the relevant subsystem, when enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/i2c: Disable i2c bus access after ->fini()Lyude Paul2019-05-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/nouveau/fault/gp100: expose MaxwellFaultBufferABen Skeggs2019-02-201-0/+2
| | | | | | | This nvclass exposes the replayable fault buffer, which will be used by SVM to manage GPU page faults. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/gp100-: support vmms with gcc/tex replayable faults enabledBen Skeggs2019-02-201-0/+2
| | | | | | | | | | | | | | Some GPU units are capable of supporting "replayable" page faults, where the execution unit will wait for SW to fixup GPU page tables rather than triggering a channel-fatal fault. This feature isn't useful (it's harmful, even) unless something like HMM is being used to manage events appearing in the replayable fault buffer, so, it's disabled by default. This commit allows a client to request it be enabled. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu: add a privileged method to directly manage PTEsBen Skeggs2019-02-201-0/+1
| | | | | | | This provides a somewhat more direct method of manipulating the GPU page tables, which will be required to support SVM. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu: store mapped flag separately from memory pointerBen Skeggs2019-02-201-0/+1
| | | | | | | This will be used to support a privileged client providing PTEs directly, without a memory object to use as a reference. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100-: expose method to determine current contextBen Skeggs2019-02-201-0/+1
| | | | | | MMU will need access to this info. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gf100-: expose fecs methods for pausing ctxswBen Skeggs2019-02-201-0/+2
| | | | | | | | MMU will need access to these. v2. Apply fix from Rhys Kidd to send correct FECS method for STOP_CTXSW. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/sec2/tu102-: instantiate SEC2 falconBen Skeggs2019-02-191-0/+1
| | | | | | Required for ACR. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/sec2: utilise engine PRI address from TOPBen Skeggs2019-02-191-0/+2
| | | | | | | Turing has its SEC2 instance in an alternate location, and this avoids needing to duplicate the code here for it. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/nvdec/gp102-: utilise engine PRI address from TOPBen Skeggs2019-02-191-0/+2
| | | | | | Turing has its NVDEC instances in an alternate location. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gsp/gv100-: instantiate GSP falconBen Skeggs2019-02-191-0/+5
| | | | | | We need this for Turing ACR, but it's present from Volta onwards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/top: add function to lookup PRI address for devicesBen Skeggs2019-02-191-0/+1
| | | | | | | Will be using this in upcoming changes to avoid the need for entirely new subdevs to deal with Turing register moves. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: define GSP subdevBen Skeggs2019-02-192-0/+12
| | | | | | Exact meaning of the acronym is unknown, but we need this for Turing ACR. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ce/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fault/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bar/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mc/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/tu102: rename implementation from tu104Ben Skeggs2019-02-191-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/volt/gf117: fix speedo readout registerIlia Mirkin2019-02-191-0/+1
| | | | | | | | | GF117 appears to use the same register as GK104 (but still with the general Fermi readout mechanism). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980 Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: increase maximum number of nvdec instances to 3Ben Skeggs2018-12-111-3/+4
| | | | | | RTX2070 appears to have 3 copies of the engine. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ce/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | Various different bits and pieces vs GV100. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fault/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | | | | | | | New registers. Currently uncertain how exactly to mask fault buffer interrupts. This will likely be corrected at around the same time as the new MC interrupt stuff has been properly figured out and implemented. For the moment, it shouldn't matter too much. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bar/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | New registers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | New flush method. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mc/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | | | | | Things are a bit different here on Turing, and will require further changes yet once I've investigated them more thoroughly. For now though, the existing GP100 code is compatible enough with one small hack to forward on fault buffer interrupts. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/tu104: initial supportBen Skeggs2018-12-111-0/+1
| | | | | | The GPU executes DEVINIT itself now, which makes our lives a bit easier. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: recognise TU104Ben Skeggs2018-12-111-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/gf100-: call into BAR to reset BARs after MMU faultBen Skeggs2018-12-111-0/+2
| | | | | | | This is needed for Turing, but we're supposed to wait for completion after re-writing the value on older GPUs anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/imem/nv50: support pinning objects in BAR2 and returning addressBen Skeggs2018-12-111-0/+2
| | | | | | | | | Various structures are accessed by the GPU through BAR2 for some reason on newer GPUs. This commit makes it more convenient to handle. Will be used for GP100- fault buffers, and GV100- fault method buffers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/tmr: detect stalled gpu timer and break out of waitsBen Skeggs2018-12-111-10/+18
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios: translate USB-C connector typeBen Skeggs2018-12-111-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/bios: translate additional memory typesBen Skeggs2018-12-112-6/+12
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: support multiple nvdec instancesBen Skeggs2018-12-111-3/+6
| | | | | | Turing GPUs can have more than one. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gr/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/ce/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fifo/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/dma/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fault/gv100: initial supportBen Skeggs2018-05-181-1/+5
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mmu/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | | | | | VEID support hacked in here, as it's the most convenient place for now. Will be refined once it's better understood. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fb/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/devinit/gv100: initial supportBen Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/core: recognise gv100Ben Skeggs2018-05-181-0/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>