1. 09 7月, 2013 1 次提交
    • D
      drm/i915: clean up media reset on gm45 · 36c0cc61
      Daniel Vetter 提交于
      Originally I've thought that this fixes up the reset issues on my
      gm45, but that was just a red herring due to b0rked testing.
      
      Still I much prefer writing the right values (all other fields are
      reserved) instead of potentially dragging gunk around. Hence also
      clear the register to 0 after a reset.
      
      Note that Cspec is a bit confused and doesn't explicitly say that all
      the other bits in this register are "reserved, mbz" like usually.
      Instead they're marked as "r/o, default value = 0" which semantically
      amounts to the same thing.
      
      v2: Stop claiming this fixes anything and return 0 if successful
      instead of stack garbage.
      
      v3: Pimp the commit message to explain exactly why I think the docs
      allow us to ditch the rmw cycle, spurred by a discussion with Chris.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36c0cc61
  2. 01 7月, 2013 2 次提交
  3. 11 6月, 2013 2 次提交
    • D
      drm/i915: consolidate ->num_shared_dplls assignement · 7c74ade1
      Daniel Vetter 提交于
      In the future this won't be just for pch plls, so move it into the
      shared dpll init code.
      
      v2: Bikeshed the uncessary {} away while applying to appease
      checkpatch.
      
      Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7c74ade1
    • D
      drm/i915: s/pch_pll/shared_dpll/ · e72f9fbf
      Daniel Vetter 提交于
      For fastboot we need some support to read out the sharing state of
      plls, at least for platforms where they can be shared (or freely
      assigned at least). Now for ivb we already have pretty extensive
      infrastructure for tracking pch plls, and it took us an aweful lot of
      tries to get that remotely right. Note that hsw could also share plls,
      but even now they're already freely assignable. So we need this on
      more than just ivb.
      
      So on top of the usual fastboot fun pll sharing seems to be an
      additional step up in fragility. Hence a common infrastructure for all
      shared/freely assignable display plls seems to be in order.
      
      The plan is to have a bit of dpll hw state readout code, which can be
      used individually, but also to fill in the pipe config. The hw state
      cross check code will then use that information to make sure that
      after every modeset every pipe still is connected to a pll which still
      has the correct configuration - a lot of the pch pll sharing bugs
      where due to incorrect sharing.
      
      We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
      job.
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e72f9fbf
  4. 10 6月, 2013 1 次提交
  5. 01 6月, 2013 3 次提交
  6. 21 5月, 2013 1 次提交
  7. 11 5月, 2013 5 次提交
  8. 23 4月, 2013 3 次提交
  9. 18 4月, 2013 4 次提交
  10. 09 4月, 2013 2 次提交
  11. 06 4月, 2013 1 次提交
  12. 02 4月, 2013 1 次提交
  13. 27 3月, 2013 2 次提交
  14. 24 3月, 2013 1 次提交
  15. 23 3月, 2013 3 次提交
  16. 07 3月, 2013 1 次提交
  17. 05 3月, 2013 1 次提交
    • D
      drm/i915: enable irqs earlier when resuming · 15239099
      Daniel Vetter 提交于
      We need it to restore the ilk rc6 context, since the gpu wait no
      requires interrupts. But in general having interrupts around should
      help in code sanity, since more and more stuff is interrupt driven.
      
      This regression has been introduced in
      
      commit 3e960501
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Nov 27 16:22:54 2012 +0000
      
          drm/i915: Rearrange code to only have a single method for waiting upon the ring
      
      Like in the driver load code we need to make sure that hotplug
      interrupts don't cause havoc with our modeset state, hence block them
      with the existing infrastructure. Again we ignore races where we might
      loose hotplug interrupts ...
      
      Note that the driver load part of the regression has already been
      fixed in
      
      commit 52d7eced
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Sat Dec 1 21:03:22 2012 +0100
      
          drm/i915: reorder setup sequence to have irqs for output setup
      
      v2: Add a note to the commit message about which patch fixed the
      driver load part of the regression. Stable kernels need to backport
      both patches.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54691
      Cc: stable@vger.kernel.org (for 3.8 only, plese backport
      			    52d7eced first)
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reported-and-Tested-by: NIlya Tumaykin <itumaykin@gmail.com>
      Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      15239099
  18. 04 3月, 2013 1 次提交
  19. 20 2月, 2013 3 次提交
  20. 14 2月, 2013 1 次提交
    • Z
      i915: ignore lid open event when resuming · b8efb17b
      Zhang Rui 提交于
      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: NZhang Rui <rui.zhang@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b8efb17b
  21. 31 1月, 2013 1 次提交