1. 04 Mar, 2013 1 commit
  2. 03 Mar, 2013 4 commits
  3. 22 Feb, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: Revert hdmi HDP pin checks · 202adf4b
      Daniel Vetter authored
      This reverts
      
      commit 8ec22b21
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Fri May 11 18:01:34 2012 +0100
      
          drm/i915/hdmi: Query the live connector status bit for G4x
      
      and
      
      commit b0ea7d37
      Author: Damien Lespiau <damien.lespiau@intel.com>
      Date:   Thu Dec 13 16:09:00 2012 +0000
      
          drm/i915/hdmi: Read the HPD status before trying to read the EDID
      
      They reliably cause HDMI to not be detected on some systems (like my
      ivb or the bug reporters gm45). To fix up the very slow unplug issues
      we might want to fire up a 2nd detect cycle a few hundred ms after
      each hotplug. But for now at least make displays work again.
      
      I somewhat suspect that this is confined to HDMI connectors, since all
      the machines I have with DP+ outputs work correctly.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52361
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org.kernel.org # for 8ec22b21Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      202adf4b
  4. 21 Feb, 2013 1 commit
  5. 19 Feb, 2013 23 commits
  6. 15 Feb, 2013 8 commits
  7. 13 Feb, 2013 2 commits
    • Zhang Rui's avatar
      i915: ignore lid open event when resuming · b8efb17b
      Zhang Rui authored
      i915 driver needs to do modeset when
      1. system resumes from sleep
      2. lid is opened
      
      In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
      thus it is the i915_resume code does the modeset rather than intel_lid_notify().
      
      But in PM_SUSPEND_FREEZE state, this will be broken because
      system is still responsive to the lid events.
      1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
      2. When we reopen the lid, intel_lid_notify() will do a modeset,
         before the system is resumed.
      here is the error log,
      
      [92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
      [92146.548076] Hardware name: VGN-Z540N
      [92146.548078] pipe_off wait timed out
      [92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
      [92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
      [92146.548175] Call Trace:
      [92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
      [92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
      [92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
      [92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
      [92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
      [92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
      [92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
      [92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
      [92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
      [92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
      [92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
      [92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
      [92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
      [92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
      [92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
      [92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
      [92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
      [92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
      [92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
      [92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
      [92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
      [92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
      [92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
      [92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
      [92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
      [92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
      [92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
      [92146.548640]  [<c1056e84>] kthread+0x94/0xa0
      [92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
      [92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
      [92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0
      
      three different modeset flags are introduced in this patch
      MODESET_ON_LID_OPEN: do modeset on next lid open event
      MODESET_DONE:  modeset already done
      MODESET_SUSPENDED:  suspended, only do modeset when system is resumed
      
      In this way,
      1. when lid is closed, MODESET_ON_LID_OPEN is set so that
         we'll do modeset on next lid open event.
      2. when lid is opened, MODESET_DONE is set
         so that duplicate lid open events will be ignored.
      3. when system suspends, MODESET_SUSPENDED is set.
         In this case, we will not do modeset on any lid events.
      
      Plus, locking mechanism is also introduced to avoid racing.
      Signed-off-by: default avatarZhang Rui <rui.zhang@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b8efb17b
    • Ben Widawsky's avatar
      drm/i915: Fix RC6VIDS encode/decode · 7083e050
      Ben Widawsky authored
      The RC6 VIDS has a linear ramp starting at 250mv, which means any values
      below 250 are invalid. The old buggy macros tried to adjust for this to
      be more flexible, but there is no need. As Dan pointed out the ENCODE
      only ever has one value. The only invalid value for decode is an input
      of 0 which means something is really wonky, and the cases where DECODE
      are used either don't matter (debug values), or would be implicitly
      correct (the check for less than 450).
      
      This patch makes simpler, easier to read macros which are actually
      correct. Maybe this patch can actually fix some bugs now.
      
      Thanks to Dan for catching this. /me hides
      
      Cc: stable@kernel.org
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7083e050