1. 17 4月, 2014 1 次提交
  2. 03 4月, 2014 1 次提交
  3. 02 4月, 2014 1 次提交
    • M
      drm: Replace crtc fb with primary plane fb (v3) · f4510a27
      Matt Roper 提交于
      Now that CRTC's have a primary plane, there's no need to track the
      framebuffer in the CRTC.  Replace all references to the CRTC fb with the
      primary plane's fb.
      
      This patch was generated by the Coccinelle semantic patching tool using
      the following rules:
      
              @@ struct drm_crtc C; @@
              -   (C).fb
              +   C.primary->fb
      
              @@ struct drm_crtc *C; @@
              -   (C)->fb
              +   C->primary->fb
      
      v3: Generate patch via coccinelle.  Actual removal of crtc->fb has been
          moved to a subsequent patch.
      
      v2: Fixup several lingering crtc->fb instances that were missed in the
          first patch iteration.  [Rob Clark]
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NRob Clark <robdclark@gmail.com>
      f4510a27
  4. 07 3月, 2014 1 次提交
  5. 03 3月, 2014 2 次提交
  6. 28 2月, 2014 1 次提交
  7. 09 1月, 2014 1 次提交
  8. 08 1月, 2014 1 次提交
  9. 25 12月, 2013 1 次提交
    • A
      drm/radeon/pm: move pm handling into the asic specific code · 6c7bccea
      Alex Deucher 提交于
      We need more control over the ordering of dpm init with
      respect to the rest of the asic.  Specifically, the SMC
      has to be initialized before the rlc and cg/pg.  The pm
      code currently initializes late in the driver, but we need
      it to happen much earlier so move pm handling into the asic
      specific callbacks.
      
      This makes dpm more reliable and makes clockgating work
      properly on CIK parts and should help on SI parts as well.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6c7bccea
  10. 16 11月, 2013 1 次提交
  11. 09 11月, 2013 1 次提交
  12. 02 11月, 2013 3 次提交
  13. 23 9月, 2013 1 次提交
  14. 11 9月, 2013 2 次提交
  15. 31 8月, 2013 1 次提交
  16. 29 8月, 2013 1 次提交
    • D
      gpu/vga_switcheroo: add driver control power feature. (v3) · 0d69704a
      Dave Airlie 提交于
      For optimus and powerxpress muxless we really want the GPU
      driver deciding when to power up/down the GPU, not userspace.
      
      This adds the ability for a driver to dynamically power up/down
      the GPU and remove the switcheroo from controlling it, the
      switcheroo reports the dynamic state to userspace also.
      
      It also adds 2 power domains, one for machine where the power
      switch is controlled outside the GPU D3 state, so the powerdown
      ordering is done correctly, and the second for the hdmi audio
      device to make sure it can resume for PCI config space accesses.
      
      v1.1: fix build with switcheroo off
      
      v2: add power domain support for radeon and v1 nvidia dsms
      v2.1: fix typo in off case
      
      v3: add audio power domain for hdmi audio + misc audio fixes
      
      v4: use PCI_SLOT macro, drop power reference on hdmi audio resume
      failure also.
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      0d69704a
  17. 08 8月, 2013 2 次提交
  18. 27 6月, 2013 1 次提交
  19. 26 6月, 2013 2 次提交
  20. 12 6月, 2013 1 次提交
  21. 30 5月, 2013 1 次提交
  22. 29 5月, 2013 2 次提交
  23. 20 5月, 2013 1 次提交
  24. 02 5月, 2013 1 次提交
  25. 24 4月, 2013 1 次提交
  26. 09 4月, 2013 1 次提交
  27. 20 2月, 2013 1 次提交
  28. 02 2月, 2013 1 次提交
  29. 31 1月, 2013 1 次提交
    • M
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming 提交于
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  30. 07 1月, 2013 1 次提交
    • M
      drm/radeon: add quirk for d3 delay during switcheroo poweron for apple macbooks · d1f9809e
      Maarten Lankhorst 提交于
      vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI
      configuration space is not restored correctly, resulting in MSI not working after switch.
      
      Only useful item in dmesg is:
      
      [   33.922807] radeon 0000:01:00.0: Refused to change power state, currently in D3
      
      I did some testing, dumping the difference in ms between first succesful switch
      from D3 to D0, and it seems that there is slightly more than 20 ms difference when
      the device is re-enabled through vga-switcheroo.
      
      So bump the re-enable d3 delay to 20 ms to handle this, which fixes msi not working
      on my system after switcheroo-ing. Default d3_delay value is PCI_PM_D3_WAIT, 10 ms.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      d1f9809e
  31. 20 12月, 2012 3 次提交