1. 23 May, 2016 8 commits
    • Ander Conselvan de Oliveira's avatar
      drm/i915: Set crtc_state->lane_count for HDMI · 2bae0304
      Ander Conselvan de Oliveira authored
      Set the lane count for HDMI to 4. This will make it easier to
      unduplicate CHV phy code.
      
      This also fixes the the soft reset programming for HDMI with CHV. After
      commit a8f327fb ("drm/i915: Clean up CHV lane soft reset
      programming"), it wouldn't set the right bits for PCS23 since it relied
      on a lane count that was never set.
      
      v2: Set lane_count in *_get_config() to please state checker. (0day)
      v3: Set lane_count for DDI in DVI mode too. (CI)
      v4: Add note about CHV soft lane reset. (Ander)
      
      Fixes: a8f327fb ("drm/i915: Clean up CHV lane soft reset programming")
      Signed-off-by: default avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: default avatarJim Bride <jim.bride@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1461761065-21195-2-git-send-email-ander.conselvan.de.oliveira@intel.com
      (cherry picked from commit d4d6279a)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      2bae0304
    • Ramalingam C's avatar
      drm/i915/BXT: Retrieving the horizontal timing for DSI · 130b62f7
      Ramalingam C authored
      Retriving the horizontal timings from the port registers as part of
      get_config().
      
      This fixes a division by zero:
      
      [   56.916557] divide error: 0000 [#1] PREEMPT SMP
      [   56.921741] Modules linked in: i915(+) drm_kms_helper syscopyarea
      sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart cf
      g80211 rfkill binfmt_misc ax88179_178a kvm_intel kvm irqbypass crc32c_intel
      efivars tpm_tis tpm fuse
      [   56.944106] CPU: 3 PID: 1097 Comm: modprobe Not tainted 4.6.0-rc4+ #433
      [   56.951501] Hardware name: Intel Corp. Broxton M/RVP, BIOS
      BXT1RVPA.X64.0131.B30.1604142217 04/14/2016
      [   56.961908] task: ffff88007a854d00 ti: ffff88007aea0000 task.ti:
      ffff88007aea0000
      [   56.970273] RIP: 0010:[<ffffffffa01235b2>]  [<ffffffffa01235b2>]
      drm_mode_hsync+0x22/0x40 [drm]
      [   56.980043] RSP: 0018:ffff88007aea3788  EFLAGS: 00010206
      [   56.985982] RAX: 000000000788b600 RBX: ffff880073c22108 RCX:
      0000000000000000
      [   56.993957] RDX: 0000000000000000 RSI: ffff88007ab06800 RDI:
      ffff880073c22108
      [   57.001935] RBP: ffff88007aea3788 R08: 0000000000000001 R09:
      ffff880073c221e8
      [   57.009903] R10: ffff880073c22108 R11: 0000000000000001 R12:
      ffff88007a300000
      [   57.017872] R13: ffff880073c22000 R14: ffff880175f78000 R15:
      ffff880175f78798
      [   57.025849] FS:  00007f105d3e6700(0000) GS:ffff88017fd80000(0000)
      knlGS:0000000000000000
      [   57.034894] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   57.041317] CR2: 00007f4d485101d0 CR3: 000000007a820000 CR4:
      00000000003406e0
      [   57.049292] Stack:
      [   57.051539]  ffff88007aea37a0 ffffffffa043b632 ffff880175f787c8
      ffff88007aea3810
      [   57.059825]  ffffffffa043d59e ffff880175f787b0 ffff88007ab68c00
      ffff88007aea37f0
      [   57.068128]  ffff880073c221e8 ffff880073c22108 ffff880175f78780
      ffff880100000000
      [   57.076430] Call Trace:
      [   57.079254]  [<ffffffffa043b632>] intel_mode_from_pipe_config+0x82/0xb0
      [i915]
      [   57.087405]  [<ffffffffa043d59e>] intel_modeset_setup_hw_state+0x55e/0xd60
      [i915]
      [   57.095847]  [<ffffffffa043ff94>] intel_modeset_init+0x8e4/0x1630 [i915]
      [   57.103415]  [<ffffffffa047bcf0>] i915_driver_load+0xbe0/0x1980 [i915]
      [   57.110745]  [<ffffffffa0116c19>] drm_dev_register+0xa9/0xc0 [drm]
      [   57.117681]  [<ffffffffa011921d>] drm_get_pci_dev+0x8d/0x1e0 [drm]
      [   57.124600]  [<ffffffff8195f942>] ? _raw_spin_unlock_irqrestore+0x42/0x70
      [   57.132253]  [<ffffffffa03b0384>] i915_pci_probe+0x34/0x50 [i915]
      [   57.139070]  [<ffffffff8149c375>] local_pci_probe+0x45/0xa0
      [   57.145303]  [<ffffffff8149d300>] ? pci_match_device+0xe0/0x110
      [   57.151924]  [<ffffffff8149d6cb>] pci_device_probe+0xdb/0x130
      [   57.158355]  [<ffffffff81579b93>] driver_probe_device+0x223/0x440
      [   57.165169]  [<ffffffff81579e85>] __driver_attach+0xd5/0x100
      [   57.171500]  [<ffffffff81579db0>] ? driver_probe_device+0x440/0x440
      [   57.178510]  [<ffffffff81577736>] bus_for_each_dev+0x66/0xa0
      [   57.184841]  [<ffffffff815793de>] driver_attach+0x1e/0x20
      [   57.190881]  [<ffffffff81578d6e>] bus_add_driver+0x1ee/0x280
      [   57.197212]  [<ffffffff8157abc0>] driver_register+0x60/0xe0
      [   57.203447]  [<ffffffff8149bc50>] __pci_register_driver+0x60/0x70
      [   57.210285]  [<ffffffffa0119450>] drm_pci_init+0xe0/0x110 [drm]
      [   57.216911]  [<ffffffff810dcd8d>] ? trace_hardirqs_on+0xd/0x10
      [   57.223434]  [<ffffffffa023a000>] ? 0xffffffffa023a000
      [   57.229237]  [<ffffffffa023a092>] i915_init+0x92/0x99 [i915]
      [   57.235570]  [<ffffffff810003db>] do_one_initcall+0xab/0x1d0
      [   57.241900]  [<ffffffff810f9eef>] ? rcu_read_lock_sched_held+0x7f/0x90
      [   57.249205]  [<ffffffff81204f18>] ? kmem_cache_alloc_trace+0x248/0x2b0
      [   57.256509]  [<ffffffff811a5eee>] ? do_init_module+0x27/0x1d9
      [   57.262934]  [<ffffffff811a5f26>] do_init_module+0x5f/0x1d9
      [   57.269167]  [<ffffffff8112392f>] load_module+0x20ef/0x27b0
      [   57.275401]  [<ffffffff8111f8e0>] ? store_uevent+0x40/0x40
      [   57.281541]  [<ffffffff81124243>] SYSC_finit_module+0xc3/0xf0
      [   57.287969]  [<ffffffff8112428e>] SyS_finit_module+0xe/0x10
      [   57.294203]  [<ffffffff81960069>] entry_SYSCALL_64_fastpath+0x1c/0xac
      [   57.301406] Code: ff 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 8b 87 d8 00 00
      00 55 48 89 e5 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9
      b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 5d c3
      [   57.322964] RIP  [<ffffffffa01235b2>] drm_mode_hsync+0x22/0x40 [drm]
      [   57.330103]  RSP <ffff88007aea3788>
      [   57.334276] ---[ end trace d414224cb2e2a4cf ]---
      [   57.339861] modprobe (1097) used greatest stack depth: 12048 bytes left
      
      Fixes: 6f0e7535 ("drm/i915/BXT: Get pipe conf from the port registers")
      Signed-off-by: default avatarRamalingam C <ramalingam.c@intel.com>
      Acked-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1461053894-5058-1-git-send-email-ramalingam.c@intel.com
      (cherry picked from commit cefc4e18)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      130b62f7
    • Chris Wilson's avatar
      drm/i915: Protect gen7 irq_seqno_barrier with uncore lock · e32da7ad
      Chris Wilson authored
      Faced with sporadic machine hangs on gen7, that mimic the issue of
      concurrent writes to the same cacheline and seem to start with
      commit 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq
      barrier on legacy gen6+), let us restore the spinlock around the mmio
      read.
      
      Fixes: 9b9ed309 (drm/i915: Remove forcewake dance from seqno/irq...)
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1461744121-27051-1-git-send-email-chris@chris-wilson.co.ukTested-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      (cherry picked from commit bcbdb6d0)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      e32da7ad
    • Ville Syrjälä's avatar
      drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms · 5fbd0418
      Ville Syrjälä authored
      Move the intel_enable_gtt() call to happen before we touch the GTT
      during resume. Right now it's done way too late. Before
      commit ebb7c78d ("agp/intel-gtt: Only register fake agp driver for gen1")
      it was actually done earlier on account of also getting called from
      the resume hook of the fake agp driver. With the fake agp driver
      no longer getting registered we must move the call up.
      
      The symptoms I've seen on my 830 machine include lowmem corruption,
      other kinds of memory corruption, and straight up hung machine during
      or just after resume. Not really sure what causes the memory corruption,
      but so far I've not seen any with this fix.
      
      I think we shouldn't really need to call this during init, but we have
      been doing that so I've decided to keep the call. However moving that
      call earlier could be prudent as well. Doing it right after the
      intel-gtt probe seems appropriate.
      
      Also tested this on 946gz,elk,ilk and all seemed quite happy with
      this change.
      
      v2: Reorder init_hw vs. enable_hw functions (Chris)
      
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: drm-intel-fixes@lists.freedesktop.org
      Fixes: ebb7c78d ("agp/intel-gtt: Only register fake agp driver for gen1")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462559755-353-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit ac840ae5)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5fbd0418
    • Ville Syrjälä's avatar
      drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT · 55d7f30e
      Ville Syrjälä authored
      DP dual mode type 1 DVI adaptors aren't required to implement any
      registers, so it's a bit hard to detect them. The best way would
      be to check the state of the CONFIG1 pin, but we have no way to
      do that. So as a last resort, check the VBT to see if the HDMI
      port is in fact a dual mode capable DP port.
      
      v2: Deal with VBT code reorganization
          Deal with DRM_DP_DUAL_MODE_UNKNOWN
          Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
          Accept both DP and HDMI dvo_port in VBT as my BSW
          at least declare its DP port as HDMI :(
      v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashank)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Reported-by: default avatarTore Anderson <tore@fud.no>
      Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462362322-31278-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      (cherry picked from commit d6199256)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      55d7f30e
    • Ville Syrjälä's avatar
      drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed · 0c2fb7c6
      Ville Syrjälä authored
      To save a bit of power, let's try to turn off the TMDS output buffers
      in DP++ adaptors when we're not driving the port.
      
      v2: Let's not forget DDI, toss in a debug message while at it
      v3: Just do the TMDS output control based on adaptor type. With the
          helper getting passed the type, we wouldn't actually have to
          check at all in the driver, but the check eliminates the debug
          output more honest
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      (cherry picked from commit b2ccb822)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      0c2fb7c6
    • Ville Syrjälä's avatar
      drm/i915: Respect DP++ adaptor TMDS clock limit · c578d152
      Ville Syrjälä authored
      Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
      and take it into account when checking the port clock.
      
      Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
      the adaptor TMDS clock limit in the modeset path, in case users are
      already "overclocking" their TMDS links. One subtle change here is that
      we'll have to respect the adaptor TMDS clock limit when we decide whether
      to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
      accidentally driving the TMDS link out of spec even when the user chose
      a mode that fits wihting the limits at 8bpc. This means you can't
      "overclock" your DP++ dongle at 12bpc anymore, but you can continue to
      do so at 8bpc.
      
      Note that for simplicity we'll use the I2C access method for all dual
      mode adaptors including type 2. Otherwise we'd have to start mixing
      DP AUX and HDMI together. In the future we may need to do that if we
      come across any board designs that don't hook up the DDC pins to the
      DP++ connectors. Such boards would obviously only work with type 2
      dual mode adaptors, and not type 1.
      
      v2: Store adaptor type under indel_hdmi->dp_dual_mode
          Deal with DRM_DP_DUAL_MODE_UNKNOWN
          Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(),
          and use it for type1 adaptors as well
      
      Cc: stable@vger.kernel.org
      Reported-by: default avatarTore Anderson <tore@fud.no>
      Fixes: 7a0baa62 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462216105-20881-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      (cherry picked from commit b1ba124d)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      c578d152
    • Ville Syrjälä's avatar
      drm: Add helper for DP++ adaptors · b3daa5ef
      Ville Syrjälä authored
      Add a helper which aids in the identification of DP dual mode
      (aka. DP++) adaptors. There are several types of adaptors
      specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
      
      Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
      may go as high as 300MHz and they provide a register informing the
      source device what the actual limit is. Supposedly also type 1 adaptors
      may optionally implement this register. This TMDS clock limit is the
      main reason why we need to identify these adaptors.
      
      Type 1 adaptors provide access to their internal registers and the sink
      DDC bus through I2C. Type 2 adaptors provide this access both via I2C
      and I2C-over-AUX. A type 2 source device may choose to implement either
      of these methods. If a source device implements the I2C-over-AUX
      method, then the driver will obviously need specific support for such
      adaptors since the port is driven like an HDMI port, but DDC
      communication happes over the AUX channel.
      
      This helper should be enough to identify the adaptor type (some
      type 1 DVI adaptors may be a slight exception) and the maximum TMDS
      clock limit. Another feature that may be available is control over
      the TMDS output buffers on the adaptor, possibly allowing for some
      power saving when the TMDS link is down.
      
      Other user controllable features that may be available in the adaptors
      are downstream i2c bus speed control when using i2c-over-aux, and
      some control over the CEC pin. I chose not to provide any helper
      functions for those since I have no use for them in i915 at this time.
      The rest of the registers in the adaptor are mostly just information,
      eg. IEEE OUI, hardware and firmware revision, etc.
      
      v2: Pass adaptor type to helper functions to ease driver implementation
          Fix a bunch of typoes (Paulo)
          Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
          the type (Paulo)
          Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
          Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
          ease future LSPCON enabling
          Remove the unused DP_DUAL_MODE_LAST_RESERVED define
      v3: Fix kernel doc function argument descriptions (Jani)
          s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
          Add kernel doc for enum drm_dp_dual_mode_type
          Actually build the docs
          Fix more typoes
      v4: Adjust code indentation of type2 adaptor detection (Shashank)
          Add debug messages for failurs cases (Shashank)
      v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
      Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
      (cherry picked from commit ede53344)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b3daa5ef
  2. 25 Apr, 2016 1 commit
  3. 24 Apr, 2016 3 commits
  4. 22 Apr, 2016 10 commits
  5. 21 Apr, 2016 1 commit
  6. 20 Apr, 2016 11 commits
  7. 19 Apr, 2016 6 commits