1. 09 5月, 2016 1 次提交
    • V
      drm/i915: Respect DP++ adaptor TMDS clock limit · b1ba124d
      Ville Syrjälä 提交于
      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: NTore 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: NVille 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: NShashank Sharma <shashank.sharma@intel.com>
      b1ba124d
  2. 29 4月, 2016 10 次提交
  3. 23 4月, 2016 1 次提交
  4. 07 4月, 2016 1 次提交
  5. 08 3月, 2016 1 次提交
  6. 07 3月, 2016 1 次提交
  7. 01 3月, 2016 1 次提交
  8. 22 2月, 2016 1 次提交
  9. 17 2月, 2016 1 次提交
  10. 11 2月, 2016 1 次提交
  11. 29 1月, 2016 1 次提交
  12. 12 1月, 2016 1 次提交
  13. 30 12月, 2015 1 次提交
  14. 23 12月, 2015 1 次提交
  15. 22 12月, 2015 2 次提交
  16. 21 12月, 2015 1 次提交
    • G
      drm/i915: Correct max delay for HDMI hotplug live status checking · 61fb3980
      Gary Wang 提交于
      The total delay of HDMI hotplug detecting with 30ms have already
      been split into a resolution of 3 retries of 10ms each, for the worst
      cases. But it still suffered from only waiting 10ms at most in
      intel_hdmi_detect(). This patch corrects it by reading hotplug status
      with 4 times at most for 30ms delay.
      
      v2:
      - straight up to loop execution for more clear in code readability
      - mdelay will replace with msleep by Daniel's new patch
      
      	drm/i915: mdelay(10) considered harmful
      
      - suggest to re-evaluate try times for being compatible to old HDMI monitor
      Reviewed-by: NCooper Chiou <cooper.chiou@intel.com>
      Tested-by: NGary Wang <gary.c.wang@intel.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      Cc: Gavin Hindman <gavin.hindman@intel.com>
      Cc: Sonika Jindal <sonika.jindal@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: NGary Wang <gary.c.wang@intel.com>
      [danvet: fixup conflict with s/mdelay/msleep/ patch.]
      Cc: drm-intel-fixes@lists.freedesktop.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      61fb3980
  17. 17 12月, 2015 2 次提交
  18. 11 12月, 2015 1 次提交
  19. 10 12月, 2015 2 次提交
  20. 02 12月, 2015 2 次提交
  21. 01 12月, 2015 1 次提交
  22. 20 11月, 2015 2 次提交
  23. 18 11月, 2015 2 次提交
    • V
      drm/i915: Type safe register read/write · f0f59a00
      Ville Syrjälä 提交于
      Make I915_READ and I915_WRITE more type safe by wrapping the register
      offset in a struct. This should eliminate most of the fumbles we've had
      with misplaced parens.
      
      This only takes care of normal mmio registers. We could extend the idea
      to other register types and define each with its own struct. That way
      you wouldn't be able to accidentally pass the wrong thing to a specific
      register access function.
      
      The gpio_reg setup is probably the ugliest thing left. But I figure I'd
      just leave it for now, and wait for some divine inspiration to strike
      before making it nice.
      
      As for the generated code, it's actually a bit better sometimes. Eg.
      looking at i915_irq_handler(), we can see the following change:
        lea    0x70024(%rdx,%rax,1),%r9d
        mov    $0x1,%edx
      - movslq %r9d,%r9
      - mov    %r9,%rsi
      - mov    %r9,-0x58(%rbp)
      - callq  *0xd8(%rbx)
      + mov    %r9d,%esi
      + mov    %r9d,-0x48(%rbp)
       callq  *0xd8(%rbx)
      
      So previously gcc thought the register offset might be signed and
      decided to sign extend it, just in case. The rest appears to be
      mostly just minor shuffling of instructions.
      
      v2: i915_mmio_reg_{offset,equal,valid}() helpers added
          s/_REG/_MMIO/ in the register defines
          mo more switch statements left to worry about
          ring_emit stuff got sorted in a prep patch
          cmd parser, lrc context and w/a batch buildup also in prep patch
          vgpu stuff cleaned up and moved to a prep patch
          all other unrelated changes split out
      v3: Rebased due to BXT DSI/BLC, MOCS, etc.
      v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
      f0f59a00
    • V
      drm/i915: Introduce a gmbus power domain · f0ab43e6
      Ville Syrjälä 提交于
      Currently the gmbus code uses intel_aux_display_runtime_get/put in an
      effort to make sure the hardware is powered up sufficiently for gmbus.
      That function only takes the runtime PM reference which on VLV/CHV/BXT
      is not enough. We need the disp2d/pipe-a well on VLV/CHV and power well
      2 on BXT. So add a new power domnain for gmbus and kill off the now
      unused intel_aux_display_runtime_get/put. And change
      intel_hdmi_set_edid() to use the gmbus power domain too since that's all
      we need there.
      
      Also toss in a BUILD_BUG_ON() to catch problems if we run out of
      bits for power domains. We're already really close to the limit...
      
      [Patrik: Add gmbus string to debugfs output]
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-5-git-send-email-patrik.jakobsson@linux.intel.com
      f0ab43e6
  24. 10 11月, 2015 1 次提交
  25. 21 10月, 2015 1 次提交