1. 15 May, 2019 2 commits
  2. 14 May, 2019 3 commits
  3. 13 May, 2019 3 commits
  4. 09 May, 2019 2 commits
  5. 08 May, 2019 2 commits
  6. 07 May, 2019 6 commits
  7. 06 May, 2019 1 commit
  8. 03 May, 2019 8 commits
  9. 02 May, 2019 5 commits
  10. 01 May, 2019 8 commits
    • Dave Airlie's avatar
      Merge branch 'linux-5.2' of git://github.com/skeggsb/linux into drm-next · 989eea61
      Dave Airlie authored
      No major changes ready for this round, but a few misc fixes instead.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      From: Ben Skeggs <skeggsb@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7+Ch=r9pt+kPRP8obo_uLscL9Hrg3xq4s92StLvgy=Mw@mail.gmail.com
      989eea61
    • Tobias Klausmann's avatar
      drm/nouveau/nouveau: forward error generated while resuming objects tree · 30df16b9
      Tobias Klausmann authored
      On a failed resume we may experience unrecoverable errors. Plumb the error code
      through to actually let the driver fail. On a reverse-prime setup this helps the
      drm subsystem to at least recover the integrated gpu.
      
      This can especially happen with secboot timing out, leaving the hardware in a
      non-functioning state.
      Signed-off-by: default avatarTobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      30df16b9
    • Colin Ian King's avatar
      drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully" · a2f07d4c
      Colin Ian King authored
      There is a spelling mistake in a nvkm_debug message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      a2f07d4c
    • Lyude Paul's avatar
      drm/nouveau/i2c: Disable i2c bus access after ->fini() · 342406e4
      Lyude Paul authored
      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: default avatarLyude Paul <lyude@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      342406e4
    • Bjorn Helgaas's avatar
      drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition · 2fbcb565
      Bjorn Helgaas authored
      Commit 3a6536c5 ("drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE")
      added a definition of ACPI_VIDEO_NOTIFY_PROBE because <acpi/video.h> didn't
      supply one.  Later, commit eff4a751 ("ACPI / video: Move
      ACPI_VIDEO_NOTIFY_* defines to acpi/video.h") moved ACPI_VIDEO_NOTIFY_PROBE
      and other definitions to <acpi/video.h>, so the copy in nouveau_display.c
      is now unnecessary.
      
      Remove the unnecessary definition from nouveau_display.c.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Hans de Goede <hdegoede@redhat.com>
      Acked-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      2fbcb565
    • Jon Derrick's avatar
      drm/nouveau/mmu: qualify vmm during dtor · 15516bf9
      Jon Derrick authored
      If the BAR initialization failed it may leave the vmm structure in an
      unitialized state, leading to a null-pointer-dereference when the vmm is
      dereferenced during teardown.
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      15516bf9
    • Jon Derrick's avatar
      drm/nouveau/bar/gf100: ensure BAR is mapped · 12e08beb
      Jon Derrick authored
      If the BAR is zero size, it indicates it was never successfully mapped.
      Ensure that the BAR is valid during initialization before attempting to
      use it.
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      12e08beb
    • Jon Derrick's avatar
      drm/nouveau/bar/nv50: ensure BAR is mapped · f10b83de
      Jon Derrick authored
      If the BAR is zero size, it indicates it was never successfully mapped.
      Ensure that the BAR is valid during initialization before attempting to
      use it.
      Signed-off-by: default avatarJon Derrick <jonathan.derrick@intel.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      f10b83de