1. 21 Jul, 2016 1 commit
  2. 20 Jul, 2016 19 commits
  3. 19 Jul, 2016 10 commits
  4. 18 Jul, 2016 2 commits
  5. 15 Jul, 2016 2 commits
  6. 14 Jul, 2016 6 commits
    • Chris Wilson's avatar
      drm/i915/fbdev: Check for the framebuffer before use · 6bc26542
      Chris Wilson authored
      If the fbdev probing fails, and in our error path we fail to clear the
      dev_priv->fbdev, then we can try and use a dangling fbdev pointer, and
      in particular a NULL fb. This could also happen in pathological cases
      where we try to operate on the fbdev prior to it being probed.
      Reported-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468431285-28264-2-git-send-email-chris@chris-wilson.co.ukReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      6bc26542
    • Chris Wilson's avatar
      drm/i915/fbdev: Drain the suspend worker on retiring · 0b8c0e9c
      Chris Wilson authored
      Since the suspend_work can arm itself if the console_lock() is currently
      held elsewhere, simply calling flush_work() doesn't guarantee that the
      work is idle upon return. To do so requires using cancel_work_sync().
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468431285-28264-1-git-send-email-chris@chris-wilson.co.ukReviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      0b8c0e9c
    • Lionel Landwerlin's avatar
      drm/i915: add missing condition for committing planes on crtc · e7852a4b
      Lionel Landwerlin authored
      The i915 driver checks for color management properties changes as part
      of a plane update. Therefore a color management update must imply a
      plane update, otherwise we never update the transformation matrixes
      and degamma/gamma LUTs.
      
      v2: add comment about moving the commit of color management registers
          to an async worker
      
      v3: Commit color management register right after vblank
      
      v4: Move back color management commit condition together with planes
          commit
      
      v5: Trigger color management commit through the planes commit (Daniel)
      
      v6: Make plane change update more readable
      
      Fixes: 20a34e78 (drm/i915: Update color management during vblank evasion.)
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: drm-intel-fixes@lists.freedesktop.org
      Signed-off-by: default avatarLionel Landwerlin <lionel.g.landwerlin@intel.com>
      References: https://lkml.org/lkml/2016/7/14/614Reviewed-and-tested-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1464183041-8478-1-git-send-email-lionel.g.landwerlin@intel.com
      e7852a4b
    • Lyude's avatar
      drm/i915: Enable polling when we don't have hpd · 19625e85
      Lyude authored
      Unfortunately, there's two situations where we lose hpd right now:
      - Runtime suspend
      - When we've shut off all of the power wells on Valleyview/Cherryview
      
      While it would be nice if this didn't cause issues, this has the
      ability to get us in some awkward states where a user won't be able to
      get their display to turn on. For instance; if we boot a Valleyview
      system without any monitors connected, it won't need any of it's power
      wells and thus shut them off. Since this causes us to lose HPD, this
      means that unless the user knows how to ssh into their machine and do a
      manual reprobe for monitors, none of the monitors they connect after
      booting will actually work.
      
      Eventually we should come up with a better fix then having to enable
      polling for this, since this makes rpm a lot less useful, but for now
      the infrastructure in i915 just isn't there yet to get hpd in these
      situations.
      
      Changes since v1:
       - Add comment explaining the addition of the if
         (!mode_config->poll_running) in intel_hpd_init()
       - Remove unneeded if (!dev->mode_config.poll_enabled) in
         i915_hpd_poll_init_work()
       - Call to drm_helper_hpd_irq_event() after we disable polling
       - Add cancel_work_sync() call to intel_hpd_cancel_work()
      
      Changes since v2:
       - Apparently dev->mode_config.poll_running doesn't actually reflect
         whether or not a poll is currently in progress, and is actually used
         for dynamic module paramter enabling/disabling. So now we instead
         keep track of our own poll_running variable in dev_priv->hotplug
       - Clean i915_hpd_poll_init_work() a little bit
      
      Changes since v3:
       - Remove the now-redundant connector loop in intel_hpd_init(), just
         rely on intel_hpd_poll_enable() for setting connector->polled
         correctly on each connector
       - Get rid of poll_running
       - Don't assign enabled in i915_hpd_poll_init_work before we actually
         lock dev->mode_config.mutex
       - Wrap enabled assignment in i915_hpd_poll_init_work() in READ_ONCE()
         for doc purposes
       - Do the same for dev_priv->hotplug.poll_enabled with WRITE_ONCE in
         intel_hpd_poll_enable()
       - Add some comments about racing not mattering in intel_hpd_poll_enable
      
      Changes since v4:
       - Rename intel_hpd_poll_enable() to intel_hpd_poll_init()
       - Drop the bool argument from intel_hpd_poll_init()
       - Remove redundant calls to intel_hpd_poll_init()
       - Rename poll_enable_work to poll_init_work
       - Add some kerneldoc for intel_hpd_poll_init()
       - Cross-reference intel_hpd_poll_init() in intel_hpd_init()
       - Just copy the loop from intel_hpd_init() in intel_hpd_poll_init()
      
      Changes since v5:
       - Minor kerneldoc nitpicks
      
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      19625e85
    • Lyude's avatar
      drm/i915/vlv: Disable HPD in valleyview_crt_detect_hotplug() · b236d7c8
      Lyude authored
      One of the things preventing us from using polling is the fact that
      calling valleyview_crt_detect_hotplug() when there's a VGA cable
      connected results in sending another hotplug. With polling enabled when
      HPD is disabled, this results in a scenario like this:
      
      - We enable power wells and reset the ADPA
      - output_poll_exec does force probe on VGA, triggering a hpd
      - HPD handler waits for poll to unlock dev->mode_config.mutex
      - output_poll_exec shuts off the ADPA, unlocks dev->mode_config.mutex
      - HPD handler runs, resets ADPA and brings us back to the start
      
      This results in an endless irq storm getting sent from the ADPA
      whenever a VGA connector gets detected in the middle of polling.
      
      Somewhat based off of the "drm/i915: Disable CRT HPD around force
      trigger" patch Ville Syrjälä sent a while back
      
      Cc: stable@vger.kernel.org
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b236d7c8
    • Lyude's avatar
      drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init() · 9504a892
      Lyude authored
      While VGA hotplugging worked(ish) before, it looks like that was mainly
      because we'd unintentionally enable it in
      valleyview_crt_detect_hotplug() when we did a force trigger. This
      doesn't work reliably enough because whenever the display powerwell on
      vlv gets disabled, the values set in VLV_ADPA get cleared and
      consequently VGA hotplugging gets disabled. This causes bugs such as one
      we found on an Intel NUC, where doing the following sequence of
      hotplugs:
      
            - Disconnect all monitors
            - Connect VGA
            - Disconnect VGA
            - Connect HDMI
      
      Would result in VGA hotplugging becoming disabled, due to the powerwells
      getting toggled in the process of connecting HDMI.
      
      Changes since v3:
       - Expose intel_crt_reset() through intel_drv.h and call that in
         vlv_display_power_well_init() instead of
         encoder->base.funcs->reset(&encoder->base);
      
      Changes since v2:
       - Use intel_encoder structs instead of drm_encoder structs
      
      Changes since v1:
       - Instead of handling the register writes ourself, we just reuse
         intel_crt_detect()
       - Instead of resetting the ADPA during display IRQ installation, we now
         reset them in vlv_display_power_well_init()
      
      Cc: stable@vger.kernel.org
      Acked-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      [danvet: Rebase over dev_priv/drm_device embedding.]
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      9504a892