1. 14 4月, 2015 1 次提交
  2. 22 1月, 2015 5 次提交
    • B
      drm/nouveau: finalise nvkm namespace switch (no binary change) · be83cd4e
      Ben Skeggs 提交于
      The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
      which will be used for the DRM part of the driver.  This is being
      done in order to make it very clear as to what part of the driver a
      given symbol belongs to, and as a minor step towards splitting the
      DRM driver out to be able to stand on its own (for virt).
      
      Because there's already a large amount of churn here anyway, this is
      as good a time as any to also switch to NVIDIA's device and chipset
      naming to ease collaboration with them.
      
      A comparison of objdump disassemblies proves no code changes.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      be83cd4e
    • B
      drm/nouveau/device: namespace + nvidia gpu names (no binary change) · 9719047b
      Ben Skeggs 提交于
      The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
      which will be used for the DRM part of the driver.  This is being
      done in order to make it very clear as to what part of the driver a
      given symbol belongs to, and as a minor step towards splitting the
      DRM driver out to be able to stand on its own (for virt).
      
      Because there's already a large amount of churn here anyway, this is
      as good a time as any to also switch to NVIDIA's device and chipset
      naming to ease collaboration with them.
      
      A comparison of objdump disassemblies proves no code changes.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      9719047b
    • B
      drm/nouveau/nvif: namespace of nvkm accessors (no binary change) · 989aa5b7
      Ben Skeggs 提交于
      NVKM is having it's namespace switched to nvkm_, which will conflict
      with these functions (which are workarounds for the fact that as of
      yet, we still aren't able to split DRM and NVKM completely).
      
      A comparison of objdump disassemblies proves no code changes.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      989aa5b7
    • B
      drm/nouveau/sw: rename from software (no binary change) · 8700287b
      Ben Skeggs 提交于
      Shorter device name, make consistent with our engine enums.
      
      The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
      which will be used for the DRM part of the driver.  This is being
      done in order to make it very clear as to what part of the driver a
      given symbol belongs to, and as a minor step towards splitting the
      DRM driver out to be able to stand on its own (for virt).
      
      Because there's already a large amount of churn here anyway, this is
      as good a time as any to also switch to NVIDIA's device and chipset
      naming to ease collaboration with them.
      
      A comparison of objdump disassemblies proves no code changes.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      8700287b
    • A
      drm/nouveau: merge nouveau_platform.ko into nouveau.ko · 055a65d5
      Alexandre Courbot 提交于
      Having the two modules separated causes various unneeded complications,
      including having to export symbols accessed between the modules. Make
      things simpler by compiling platform device support into nouveau.ko.
      Platform device support remains optional and is only compiled on Tegra.
      Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
      Reviewed-by: NVince Hsu <vinceh@nvidia.com>
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      055a65d5
  3. 02 12月, 2014 2 次提交
  4. 02 10月, 2014 1 次提交
  5. 15 9月, 2014 1 次提交
  6. 11 9月, 2014 1 次提交
    • B
      PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device · b440bde7
      Bjorn Helgaas 提交于
      Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold),
      normally generates a hot-remove event that unbinds the driver.
      
      Some drivers expect to remain bound to a device even while they power it
      off and back on again.  This can be dangerous, because if the device is
      removed or replaced while it is powered off, the driver doesn't know that
      anything changed.  But some drivers accept that risk.
      
      Add pci_ignore_hotplug() for use by drivers that know their device cannot
      be removed.  Using pci_ignore_hotplug() tells the PCI core that hot-plug
      events for the device should be ignored.
      
      The radeon and nouveau drivers use this to switch between a low-power,
      integrated GPU and a higher-power, higher-performance discrete GPU.  They
      power off the unused GPU, but they want to remain bound to it.
      
      This is a reimplementation of f244d8b6 ("ACPIPHP / radeon / nouveau:
      Fix VGA switcheroo problem related to hotplug") but extends it to work with
      both acpiphp and pciehp.
      
      This fixes a problem where systems with dual GPUs using the radeon drivers
      become unusable, freezing every few seconds (see bugzillas below).  The
      resume of the radeon device may also fail, e.g.,
      
      This fixes problems on dual GPU systems where the radeon driver becomes
      unusable because of problems while suspending the device, as in bug 79701:
      
          [drm] radeon: finishing device.
          radeon 0000:01:00.0: Userspace still has active objects !
          radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free
          ...
          WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]()
          trying to unbind memory from uninitialized GART !
      
      or while resuming it, as in bug 77261:
      
          radeon 0000:01:00.0: ring 0 stalled for more than 10158msec
          radeon 0000:01:00.0: GPU lockup ...
          radeon 0000:01:00.0: GPU pci config reset
          pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1)
          radeon 0000:01:00.0: GPU reset succeeded, trying to resume
          *ERROR* radeon: dpm resume failed
          radeon 0000:01:00.0: Wait for MC idle timedout !
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701Reported-by: NShawn Starr <shawn.starr@rogers.com>
      Reported-by: NJose P. <lbdkmjdf@sharklasers.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NAlex Deucher <alexander.deucher@amd.com>
      Acked-by: NRajat Jain <rajatxjain@gmail.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NDave Airlie <airlied@redhat.com>
      CC: stable@vger.kernel.org	# v3.15+
      b440bde7
  7. 10 9月, 2014 1 次提交
  8. 10 8月, 2014 12 次提交
  9. 09 7月, 2014 1 次提交
  10. 08 7月, 2014 1 次提交
    • B
      drm/nouveau/kms: restore fbcon after display has been resumed · 028791bb
      Ben Skeggs 提交于
      Under some complicated circumstances (boot, suspend, resume, attach
      second display, suspend, resume, suspend, detach second display,
      resume, suspend, attach second display, resume), the fb_set_suspend()
      call can somehow result in a modeset being attempted before we're
      ready for it and things blow up in fun ways.
      
      Running display init first fixes the issue.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      028791bb
  11. 02 4月, 2014 1 次提交
  12. 27 3月, 2014 1 次提交
  13. 26 3月, 2014 5 次提交
  14. 18 2月, 2014 1 次提交
  15. 30 1月, 2014 2 次提交
  16. 16 12月, 2013 1 次提交
  17. 14 11月, 2013 1 次提交
  18. 08 11月, 2013 2 次提交