1. 05 Mar, 2013 1 commit
    • Daniel Vetter's avatar
      drm/i915: enable irqs earlier when resuming · 15239099
      Daniel Vetter authored
      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: default avatarIlya Tumaykin <itumaykin@gmail.com>
      Reviewed-by: Chris wilson <chris@chris-wilson.co.uk> (v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      15239099
  2. 03 Mar, 2013 1 commit
  3. 13 Feb, 2013 1 commit
    • 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
  4. 31 Jan, 2013 1 commit
  5. 27 Jan, 2013 1 commit
  6. 24 Jan, 2013 1 commit
  7. 20 Jan, 2013 1 commit
  8. 03 Jan, 2013 1 commit
    • Greg Kroah-Hartman's avatar
      Drivers: gpu: remove __dev* attributes. · 56550d94
      Greg Kroah-Hartman authored
      
      
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, and __devexit
      from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: David Airlie <airlied@linux.ie>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56550d94
  9. 11 Dec, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: Fixup hpd irq register setup ordering · 20afbda2
      Daniel Vetter authored
      For GMCH platforms we set up the hpd irq registers in the irq
      postinstall hook. But since we only enable the irq sources we actually
      need in PORT_HOTPLUG_EN/STATUS, taking dev_priv->hotplug_supported_mask
      into account, no hpd interrupt sources is enabled since
      
      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
      
      Wrongly set-up interrupts also lead to broken hw-based load-detection
      on at least GM45, resulting in ghost VGA/TV-out outputs.
      
      To fix this, delay the hotplug register setup until after all outputs
      are set up, by moving it into a new dev_priv->display.hpd_irq_callback.
      We might also move the PCH_SPLIT platforms to such a setup eventually.
      
      Another funny part is that we need to delay the fbdev initial config
      probing until after the hpd regs are setup, for otherwise it'll detect
      ghost outputs. But we can only enable the hpd interrupt handling
      itself (and the output polling) _after_ that initial scan, due to
      massive locking brain-damage in the fbdev setup code. Add a big
      comment to explain this cute little dragon lair.
      
      v2: Encapsulate all the fbdev handling by wrapping the move call into
      intel_fbdev_initial_config in intel_fb.c. Requested by Chris Wilson.
      
      v3: Applied bikeshed from Jesse Barnes.
      
      v4: Imre Deak noticed that we also need to call intel_hpd_init after
      the drm_irqinstall calls in the gpu reset and resume paths - otherwise
      hotplug will be broken. Also improve the comment a bit about why
      hpd_init needs to be called before we set up the initial fbdev config.
      
      Bugzilla: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54943
      
      
      Reported-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      20afbda2
  10. 10 Dec, 2012 1 commit
    • Paulo Zanoni's avatar
      drm/i915: add lpt_init_pch_refclk · dde86e2d
      Paulo Zanoni authored
      
      
      We need this code to init the PCH SSC refclk and the FDI registers.
      The BIOS does this too and that's why VGA worked before this patch,
      until you tried to suspend the machine...
      
      This patch implements the "Sequence to enable CLKOUT_DP for FDI usage
      and configure PCH FDI/IO" from our documentation.
      
      v2:
      - Squash Damien Lespiau's reset spelling fix on top.
      - Add a comment that we don't need to bother about the ULT special
        case Damien noticed, since ULT won't have VGA.
      - Add a comment to rip out the SDV codepaths once haswell ships for
        real.
      
      Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      dde86e2d
  11. 29 Nov, 2012 1 commit
  12. 23 Nov, 2012 1 commit
  13. 21 Nov, 2012 4 commits
  14. 11 Nov, 2012 8 commits
  15. 18 Oct, 2012 2 commits
  16. 17 Oct, 2012 1 commit
    • Rodrigo Vivi's avatar
      drm/i915: Insert i915_preliminary_hw_support variable. · 0a3af268
      Rodrigo Vivi authored
      
      
      On the worst scenario, users with new hardwares and old kernel from
      enabling times can get black screens.  So, from now on, this
      perliminary_hw_support module parameter shall be used by all upcoming
      platforms that are still under enabling. The second option would be to
      merge the pci ids after basic modeset works, but that makes testing
      and development while bringing up hw a rather tedious afair.
      
      Although it is uncomfortable for developers use this extra variable it
      brings more stability for end users.
      
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@gmail.com>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      [danvet: dropped the i915_ param prefix, i915.i915_ is just tedious.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      0a3af268
  17. 02 Oct, 2012 2 commits
  18. 06 Sep, 2012 2 commits
    • Daniel Vetter's avatar
      drm/i915: no longer call drm_helper_resume_force_mode · 9dc10f37
      Daniel Vetter authored
      
      
      Since this only calls crtc helper functions, of which a shocking
      amount are NULL.
      
      Now the curious thing is how the new modeset code worked with this
      function call still present:
      
      Thanks to the hw state readout and the suspend fixes to properly
      quiescent the register state, nothing is actually enabled at resume
      (if the bios doesn't set up anything). Which means resume_force_mode
      doesn't actually do anything and hence nothing blows up at resume
      time.
      
      The other reason things do work is that the fbcon layer has it's own
      resume notifier callback, which restores the mode. And thanks to the
      force vt switch at suspend/resume, that then forces X to restore it's
      own mode.
      
      Hence everything still worked (as long as the bios doesn't enable
      anything). And we can just kill the call to resume_force_mode.
      
      The upside of both this patch and the preceeding patch to quiescent
      the modeset state is that our resume path is much simpler:
      - We now longer restore bogus register values (which most often would
        enable the backlight a bit and a few ports), causing flickering.
      - We now longer call resume_force_mode to restore a mode that the
        fbcon layer would overwrite right away anyway.
      
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9dc10f37
    • Daniel Vetter's avatar
      drm/i915: disable all crtcs at suspend time · a261b246
      Daniel Vetter authored
      
      
      We need this to avoid confusing the hw state readout code with the cpt
      pch plls at resume time: We'd read the new pipe state (which is
      disabled), but still believe that we have a life pll connected to that
      pipe (from before the suspend). Hence properly disable pipes to clear
      out all the residual state.
      
      This has the neat side-effect that we don't enable ports prematurely
      by restoring bogus state from the saved register values.
      
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a261b246
  19. 05 Sep, 2012 1 commit
    • Daniel Vetter's avatar
      drm/i915: read out the modeset hw state at load and resume time · 24929352
      Daniel Vetter authored
      
      
      ... instead of resetting a few things and hoping that this will work
      out.
      
      To properly disable the output pipelines at the initial modeset after
      resume or boot up we need to have an accurate picture of which outputs
      are enabled and connected to which crtcs. Otherwise we risk disabling
      things at the wrong time, which can lead to hangs (or at least royally
      confused panels), both requiring a walk to the reset button to fix.
      
      Hence read out the hw state with the freshly introduce get_hw_state
      functions and then sanitize it afterwards.
      
      For a full modeset readout (which would allow us to avoid the initial
      modeset at boot up) a few things are still missing:
      - Reading out the mode from the pipe, especially the dotclock
        computation is quite some fun.
      - Reading out the parameters for the stolen memory framebuffer and
        wrapping it up.
      - Reading out the pch pll connections - luckily the disable code
        simply bails out if the crtc doesn't have a pch pll attached (even
        for configurations that would need one).
      
      This patch here turned up tons of smelly stuff around resume: We
      restore tons of register in seemingly random way (well, not quite, but
      we're not too careful either), which leaves the hw in a rather
      ill-defined state: E.g. the port registers are sometimes
      unconditionally restore (lvds, crt), leaving us with an active
      encoder/connector but no active pipe connected to it. Luckily the hw
      state sanitizer detects this madness and fixes things up a bit.
      
      v2: When checking whether an encoder with active connectors has a crtc
      wire up to it, check for both the crtc _and_ it's active state.
      
      v3:
      - Extract intel_sanitize_encoder.
      - Manually disable active encoders without an active pipe.
      
      v4: Correclty fix up the pipe<->plane mapping on machines where we
      switch pipes/planes. Noticed by Chris Wilson, who also provided the
      fixup.
      
      v5: Spelling fix in a comment, noticed by Paulo Zanoni
      
      Reviewed-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      24929352
  20. 22 Aug, 2012 1 commit
  21. 07 Aug, 2012 1 commit
  22. 25 Jul, 2012 2 commits
  23. 19 Jul, 2012 1 commit
  24. 05 Jul, 2012 3 commits
    • Daniel Vetter's avatar
      drm/i915: don't trylock in the gpu reset code · d54a02c0
      Daniel Vetter authored
      
      
      Simply failing to reset the gpu because someone else might still hold
      the mutex isn't a great idea - I see reliable silent reset failures.
      And gpu reset simply needs to be reliable and Just Work.
      
      "But ... the deadlocks!"
      
      We already kick all processes waiting for the gpu before launching the
      reset work item. New waiters need to check the wedging state anyway
      and then bail out. If we have places that can deadlock, we simply need
      to fix them.
      
      "But ... testing!"
      
      We have the gpu hangman, and if the current gpu load gem_exec_nop
      isn't good enough to hit a specific case, we can add a new one.
      
      "But ...  don't we return -EAGAIN for non-interruptible calls to
      wait_seqno now?"
      
      Yep, but this problem already exists in the current code. A follow up
      patch will remedy this by returning -EIO for non-interruptible sleeps
      if the gpu died and the low-level wait bails out with -EAGAIN.
      
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-Off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      d54a02c0
    • Paulo Zanoni's avatar
      drm/i915: don't ironlake_init_pch_refclk() on LPT · 40579abe
      Paulo Zanoni authored
      
      
      This function is used to set the PCH_DREF_CONTROL register, which does
      not exist on LPT anymore.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      40579abe
    • Paulo Zanoni's avatar
      drm/i915: get rid of dev_priv->info->has_pch_split · 45e6e3a1
      Paulo Zanoni authored
      
      
      Previously we had has_pch_split to tell us whether we had a PCH or not
      and we also had dev_priv->pch_type to tell us which kind of PCH it
      was, but it could only be used if we were 100% sure we did have a PCH.
      Now that PCH_NONE was added to dev_priv->pch_type we don't need
      has_pch_split anymore: we can just check for pch_type != PCH_NONE.
      
      The HAS_PCH_{IBX,CPT,LPT} macros use dev_priv->pch_type, so they can
      only be called after intel_detect_pch. The HAS_PCH_SPLIT macro looks
      at dev_priv->info->has_pch_split, which is available earlier.
      
      Since the goal is to implement HAS_PCH_SPLIT using dev_priv->pch_type
      instead of dev_priv->info->has_pch_split, we need to make sure that
      intel_detect_pch is called before any calls to HAS_PCH_SPLIT are made.
      So we moved the intel_detect_pch call to an earlier stage.
      
      Signed-off-by: default avatarPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      45e6e3a1