1. 09 May, 2017 7 commits
  2. 08 May, 2017 15 commits
  3. 04 May, 2017 10 commits
  4. 03 May, 2017 1 commit
  5. 02 May, 2017 3 commits
  6. 01 May, 2017 1 commit
  7. 29 Apr, 2017 3 commits
    • Mario Kleiner's avatar
      drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection · 271393ba
      Mario Kleiner authored
      A missing u64 cast causes a 32-Bit wraparound from
      4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected
      if card has 4096 Mib per FBP.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Reviewed-by: default avatarKarol Herbst <karolherbst@gmail.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      271393ba
    • Wei Yongjun's avatar
      drm/nouveau/secboot/gm20b: fix the error return code in gm20b_secboot_tegra_read_wpr() · 48907c23
      Wei Yongjun authored
      The error return code PTR_ERR(mc) is always 0 since mc is
      equal to 0 in this error handling case.
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      48907c23
    • Mario Kleiner's avatar
      drm/nouveau/kms: Increase max retries in scanout position queries. · 60b95d70
      Mario Kleiner authored
      So far we only allowed for 1 retry and just failed the query
      - and thereby high precision vblank timestamping - if we did
      not get a reasonable result, as such a failure wasn't considered
      all too horrible. There are a few NVidia gpu models out there which
      may need a bit more than 1 retry to get a successful query result
      under some conditions.
      
      Since Linux 4.4 the update code for vblank counter and timestamp
      in drm_update_vblank_count() changed so that the implementation
      assumes that high precision vblank timestamping of a kms driver
      either consistently succeeds or consistently fails for a given
      video mode and encoder/connector combo. Iow. switching from success
      to fail or vice versa on a modeset or connector change is ok, but
      spurious temporary failure for a given setup can confuse the core
      code and potentially cause bad miscounting of vblanks and confusion
      or hangs in userspace clients which rely on vblank  stuff, e.g.,
      desktop compositors.
      
      Therefore change the max retry count to a larger number - more than
      any gpu so far is known to need to succeed, but still low enough
      so that these queries which do also happen in vblank interrupt are
      still fast enough to be not disastrously long if something would
      go badly wrong with them.
      
      As such sporadic retries only happen seldom even on affected gpu's,
      this could mean a vblank irq could take a few dozen microseconds
      longer every few hours of uptime -- better than a desktop compositor
      randomly hanging every couple of hours or days of uptime in a hard
      to reproduce manner.
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
      60b95d70