1. 10 4月, 2010 1 次提交
  2. 03 4月, 2010 1 次提交
  3. 26 3月, 2010 1 次提交
    • E
      drm/i915: Rename intel_output to intel_encoder. · 21d40d37
      Eric Anholt 提交于
      The intel_output naming is inherited from the UMS code, which had a
      structure of screen -> CRTC -> output.  The DRM code has an additional
      notion of encoder/connector, so the structure is screen -> CRTC ->
      encoder -> connector.  This is a useful structure for SDVO encoders
      which can support multiple connectors (each of which requires
      different programming in the one encoder and could be connected to
      different CRTCs), or for DVI-I, where multiple encoders feed into the
      connector for whether it's used for digital or analog.  Most of our
      code is encoder-related, so transition it to talking about encoders
      before we start trying to distinguish connectors.
      
      This patch is produced by sed s/intel_output/intel_encoder/ over the
      driver.
      Signed-off-by: NEric Anholt <eric@anholt.net>
      21d40d37
  4. 24 3月, 2010 1 次提交
  5. 27 2月, 2010 3 次提交
  6. 23 2月, 2010 1 次提交
  7. 16 2月, 2010 1 次提交
  8. 05 2月, 2010 1 次提交
  9. 30 1月, 2010 1 次提交
  10. 16 1月, 2010 1 次提交
    • J
      drm/i915: disable LVDS downclock by default · 33814341
      Jesse Barnes 提交于
      Many platform support this feature, and it can provide significant
      power savings when the reduced refresh rate is low.  However, on some
      platforms a secondary (reduced) timing is provided but not actually
      supported by the hardware.  This results in undesirable flicker at
      runtime.
      
      So disable the feature by default, but allow users to opt-in to the
      reduced clock behavior with a new module parameter, lvds_downclock,
      that can be set to 1 to enable the feature.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      33814341
  11. 08 1月, 2010 1 次提交
  12. 17 12月, 2009 3 次提交
    • Z
      drm/i915: Update LVDS connector status when receiving ACPI LID event · a2565377
      Zhao Yakui 提交于
      Dirk reports that nothing is displayed on LVDS when using ubuntu 9.1 after
      close/reopen the LID. And I also reproduce this issue on another laptop.
      After some tests and debug, it seems that it is related with that the
      LVDS status is not updated in time in course of suspend/resume.
      
      Now the LID state is used to check whether the LVDS is connected or
      disconnected. And when the LID is closed, it means that the LVDS is
      disconnected. When it is reopened, it means that the LVDS is connected.
      At the same time on some distributions the LID event is also used to put
      the system into suspend state. When the LID is closed, the system will enter
      the suspend state. When the LID is reopened, the system will be resumed.
      
      In such case when the LID is closed, user-space script will receive the LID
      notification event and  detect the LVDS as disconnected. Then the system will
      enter the suspended state. When the LID is reopened, the system will be
      resumed. As the LVDS status is not updated in course of resume, it will cause
      that the LVDS connector is marked as unused and disabled. After the resume is
      finished,user-space script will try to configure the display mode for LVDS.
      But unfortunately as the LVDS status is not updated in time and it is still
      marked as disconnected, the LVDS and its corresponding CRTC will be disabled
      again in the function of drm_helper_disable_unused_functions after changing
      mode for LVDS.
      
      So we had better check and update the status of LVDS connector after receiving
      the LID notication event. Then after the system is resumed from suspended
      state, we can set the display mode for LVDS correctly.
      Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
      Reported-by: NDirk Hohndel <hohndel@infradead.org>
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      CC: stable@kernel.org
      Signed-off-by: NEric Anholt <eric@anholt.net>
      a2565377
    • Z
      drm/i915: Add MALATA PC-81005 to ACPI LID quirk list · a3cb5195
      Zhao Yakui 提交于
      The MALATA PC-81005 laptop always reports that the LID status is closed and we
      can't use it reliabily for LVDS detection. So add this box into the quirk list.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=25523Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
      Review-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Tested-by: NHector <hector1987@gmail.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      a3cb5195
    • M
      drm/i915: Don't check for lid presence when detecting LVDS · 11ba1592
      Matthew Garrett 提交于
      Checking for the presence of a lid in order to validate whether or not
      an LVDS display exists fails on some development platforms that implement
      a lid device but allow the LVDS to be disabled. The VBT is correctly
      updated, but Linux assumes that an LVDS is still present and lies to
      userspace. Remove the lid check and trust the VBT.
      Signed-off-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      11ba1592
  13. 08 12月, 2009 1 次提交
  14. 02 12月, 2009 2 次提交
  15. 01 12月, 2009 1 次提交
  16. 26 11月, 2009 2 次提交
  17. 25 11月, 2009 1 次提交
  18. 06 11月, 2009 1 次提交
  19. 03 11月, 2009 1 次提交
    • L
      i915: fix intel graphics suspend breakage due to resume/lid event confusion · c9354c85
      Linus Torvalds 提交于
      In commit c1c7af60 ("drm/i915: force
      mode set at lid open time") the intel graphics driver was taught to
      restore the LVDS mode on lid open.
      
      That caused problems with interaction with the suspend/resume code,
      which commonly runs at the same time (suspend is often caused by the lid
      close event, while lid open is commonly a resume event), which was
      worked around with in commit 06891e27
      ("drm/i915: fix suspend/resume breakage in lid notifier").
      
      However, in the meantime the lid event code had also grown a user event
      notifier (commit 06324194: "drm/i915:
      generate a KMS uevent at lid open/close time"), and now _that_ causes
      problems with suspend/resume and some versions of Xorg reacting to those
      uevents by setting the mode.
      
      So this effectively reverts that commit 06324194, and makes the lid
      open protection logic against suspend/resume more explicit.  This fixes
      at least one laptop. See
      
      	http://bugzilla.kernel.org/show_bug.cgi?id=14484
      
      for more details.
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
      Cc: Eric Anholt <eric@anholt.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c9354c85
  20. 14 10月, 2009 1 次提交
  21. 18 9月, 2009 3 次提交
  22. 11 9月, 2009 3 次提交
  23. 25 8月, 2009 1 次提交
  24. 19 8月, 2009 1 次提交
    • J
      drm: clarify scaling property names · 53bd8389
      Jesse Barnes 提交于
      Now that we're using the scaling property in the Intel driver I noticed
      that the names were a bit confusing.  I've corrected them according to
      our discussion on IRC and the mailing list, though I've left out
      potential new additions for a new scaling property with an integer (or
      two) for the scaling factor.  None of the drivers implement that today,
      but if someone wants to do it, I think it could be done with the
      addition of a single new type and a new property to describe the
      scaling factor in the X and Y directions.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Acked-by: NAlex Deucher <alexdeucher@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      53bd8389
  25. 04 8月, 2009 1 次提交
  26. 30 7月, 2009 1 次提交
  27. 14 7月, 2009 1 次提交
  28. 10 7月, 2009 1 次提交
  29. 02 7月, 2009 1 次提交
  30. 23 6月, 2009 1 次提交