1. 01 2月, 2017 3 次提交
  2. 25 1月, 2017 3 次提交
    • J
      drm/i915: Add support for audio driver notifications · 46d196ec
      Jerome Anand 提交于
      Notifiations like mode change, hot plug and edid to
      the audio driver are added. This is inturn used by the
      audio driver for its functionality.
      
      A new interface file capturing the notifications needed by the
      audio driver is added
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NJerome Anand <jerome.anand@intel.com>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      46d196ec
    • J
      drm/i915: setup bridge for HDMI LPE audio driver · eef57324
      Jerome Anand 提交于
      Enable support for HDMI LPE audio mode on Baytrail and
      Cherrytrail when HDaudio controller is not detected
      
      Setup minimum required resources during i915_driver_load:
      1. Create a platform device to share MMIO/IRQ resources
      2. Make the platform device child of i915 device for runtime PM.
      3. Create IRQ chip to forward HDMI LPE audio irqs.
      
      HDMI LPE audio driver (a standalone sound driver) probes the
      LPE audio device and creates a new sound card.
      Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: NJerome Anand <jerome.anand@intel.com>
      Acked-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      eef57324
    • C
      drm/i915: Move atomic state free from out of fence release · 6f0f02dc
      Chris Wilson 提交于
      Fences are required to support being released from under an atomic context.
      The drm_atomic_state struct may take a mutex when being released and so
      we cannot drop a reference to the drm_atomic_state from the fence release
      path directly, and so we need to defer that unreference to a worker.
      
      [  326.576697] WARNING: CPU: 2 PID: 366 at kernel/sched/core.c:7737 __might_sleep+0x5d/0x80
      [  326.576816] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffc0359549>] intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.576818] Modules linked in: rfcomm fuse snd_hda_codec_hdmi bnep snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer input_leds led_class snd punit_atom_debug btusb btrtl btbcm btintel intel_rapl bluetooth i915 drm_kms_helper syscopyarea sysfillrect iwlwifi sysimgblt soundcore fb_sys_fops mei_txe cfg80211 drm pwm_lpss_platform pwm_lpss pinctrl_cherryview fjes acpi_pad parport_pc ppdev parport autofs4
      [  326.576899] CPU: 2 PID: 366 Comm: i915/signal:0 Tainted: G     U          4.10.0-rc3-patser+ #5030
      [  326.576902] Hardware name:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
      [  326.576905] Call Trace:
      [  326.576920]  dump_stack+0x4d/0x6d
      [  326.576926]  __warn+0xc0/0xe0
      [  326.576931]  warn_slowpath_fmt+0x5a/0x80
      [  326.577004]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577075]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577079]  __might_sleep+0x5d/0x80
      [  326.577087]  mutex_lock+0x1b/0x40
      [  326.577133]  drm_property_free_blob+0x1e/0x80 [drm]
      [  326.577167]  ? drm_property_destroy+0xe0/0xe0 [drm]
      [  326.577200]  drm_mode_object_unreference+0x5c/0x70 [drm]
      [  326.577233]  drm_property_unreference_blob+0xe/0x10 [drm]
      [  326.577260]  __drm_atomic_helper_crtc_destroy_state+0x14/0x40 [drm_kms_helper]
      [  326.577278]  drm_atomic_helper_crtc_destroy_state+0x10/0x20 [drm_kms_helper]
      [  326.577352]  intel_crtc_destroy_state+0x9/0x10 [i915]
      [  326.577388]  drm_atomic_state_default_clear+0xea/0x1d0 [drm]
      [  326.577462]  intel_atomic_state_clear+0xd/0x20 [i915]
      [  326.577497]  drm_atomic_state_clear+0x1a/0x30 [drm]
      [  326.577532]  __drm_atomic_state_free+0x13/0x60 [drm]
      [  326.577607]  intel_atomic_commit_ready+0x6f/0x78 [i915]
      [  326.577670]  i915_sw_fence_release+0x3a/0x50 [i915]
      [  326.577733]  dma_i915_sw_fence_wake+0x39/0x80 [i915]
      [  326.577741]  dma_fence_signal+0xda/0x120
      [  326.577812]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
      [  326.577884]  intel_breadcrumbs_signaler+0xb1/0x270 [i915]
      [  326.577889]  kthread+0x127/0x130
      [  326.577961]  ? intel_engine_remove_wait+0x1a0/0x1a0 [i915]
      [  326.577964]  ? kthread_stop+0x120/0x120
      [  326.577970]  ret_from_fork+0x22/0x30
      
      Fixes: c004a90b ("drm/i915: Restore nonblocking awaits for modesetting")
      Reported-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170123212939.30345-1-chris@chris-wilson.co.uk
      Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit eb955eee)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      6f0f02dc
  3. 23 1月, 2017 1 次提交
  4. 19 1月, 2017 4 次提交
  5. 18 1月, 2017 1 次提交
  6. 13 1月, 2017 2 次提交
  7. 11 1月, 2017 3 次提交
  8. 10 1月, 2017 5 次提交
  9. 09 1月, 2017 1 次提交
  10. 07 1月, 2017 2 次提交
  11. 06 1月, 2017 1 次提交
  12. 05 1月, 2017 2 次提交
  13. 02 1月, 2017 1 次提交
  14. 31 12月, 2016 4 次提交
  15. 26 12月, 2016 1 次提交
  16. 24 12月, 2016 2 次提交
  17. 22 12月, 2016 1 次提交
  18. 20 12月, 2016 2 次提交
    • I
      drm/i915/gen9: Fix PCODE polling during CDCLK change notification · 2c7d0602
      Imre Deak 提交于
      commit 848496e5
      Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Date:   Wed Jul 13 16:32:03 2016 +0300
      
          drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
      
      increased the timeout to match the spec, but we still see a timeout on
      at least one SKL. A CDCLK change request following the failed one will
      succeed nevertheless.
      
      I could reproduce this problem easily by running kms_pipe_crc_basic in a
      loop. In all failure cases _wait_for() was pre-empted for >3ms and so in
      the worst case - when the pre-emption happened right after calculating
      timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only
      once which failed and so _wait_for() timed out. As opposed to this the
      spec says to keep retrying the request for at most a 3ms period.
      
      To fix this send the first request explicitly to guarantee that there is
      3ms between the first and last request. Though this matches the spec, I
      noticed that in rare cases this can still time out if we sent only a few
      requests (in the worst case 2) _and_ PCODE is busy for some reason even
      after a previous request and a 3ms delay. To work around this retry the
      polling with pre-emption disabled to maximize the number of requests.
      Also increase the timeout to 10ms to account for interrupts that could
      reduce the number of requests. With this change I couldn't trigger
      the problem.
      
      v2:
      - Use 1ms poll period instead of 10us. (Chris)
      v3:
      - Poll with pre-emption disabled to increase the number of request
        attempts. (Ville, Chris)
      - Factor out a helper to poll, it's also needed by the next patch.
      v4:
      - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the
        reply is generic. (Ville)
      v5:
      - List the request specific timeout values as code comment. (Ville)
      v6:
      - Try the poll first with preemption enabled.
      - Add code comment about first request being queued by PCODE. (Art)
      - Add timeout_base_ms argument. (Ville)
      v7:
      - Clarify code comment about first queued request. (Chris)
      
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Art Runyan <arthur.j.runyan@intel.com>
      Cc: <stable@vger.kernel.org> # v4.2- : 3b2c1710 : drm/i915: Wait up to 3ms
      Cc: <stable@vger.kernel.org> # v4.2-
      Fixes: 5d96d8af ("drm/i915/skl: Deinit/init the display at suspend/resume")
      Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929
      Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-1-git-send-email-imre.deak@intel.com
      (cherry picked from commit a0b8a1fe)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2c7d0602
    • R
      drm/i915: Expand is_lp backwards to gen8_lp and gen7_lp. · 8727dc09
      Rodrigo Vivi 提交于
      Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp)
      are both Atom platforms like Broxton/Apollolake and Geminilake.
      
      So let's expand this is_lp back to these platforms and
      create the IS_LP(dev_priv) so we can start simplifying a bit
      our if/else for platform lists.
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1482096988-400-1-git-send-email-rodrigo.vivi@intel.com
      8727dc09
  19. 19 12月, 2016 1 次提交