1. 05 Dec, 2017 2 commits
  2. 01 Sep, 2017 1 commit
  3. 27 Jul, 2017 1 commit
  4. 02 Jun, 2017 1 commit
  5. 24 Jan, 2017 1 commit
  6. 07 Dec, 2016 1 commit
  7. 02 Dec, 2016 1 commit
  8. 01 Dec, 2016 2 commits
  9. 17 Oct, 2016 1 commit
  10. 14 Oct, 2016 3 commits
  11. 22 Aug, 2016 2 commits
  12. 05 Jul, 2016 1 commit
  13. 04 Jul, 2016 1 commit
  14. 30 Jun, 2016 1 commit
  15. 12 Apr, 2016 3 commits
  16. 07 Apr, 2016 1 commit
  17. 11 Mar, 2016 1 commit
  18. 09 Mar, 2016 1 commit
  19. 10 Feb, 2016 2 commits
  20. 10 Dec, 2015 1 commit
  21. 02 Dec, 2015 3 commits
  22. 18 Nov, 2015 2 commits
    • Ville Syrjälä's avatar
      drm/i915: Type safe register read/write · f0f59a00
      Ville Syrjälä authored
      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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris 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
    • Ville Syrjälä's avatar
      drm/i915: Streamline gpio_mmio_base deduction · b2e8c6cd
      Ville Syrjälä authored
      If we ignore the BXT situation, we can observe that the only variables
      affecting gpio_mmio_base is IS_VALLEVIEW and HAS_GMCH_DISPLAY. The BXT
      situation we can fit into the same pattern if we change gmbus_pins_bxt[]
      to house the GMCH GPIO register offsets (like we do for all other
      platfotms). So let's do that.
      
      We could even simplify the VLV situation more by including the
      display_mmio_offset in the GPIO register defines, but let's leave it be
      for now.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-13-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b2e8c6cd
  23. 17 Nov, 2015 1 commit
  24. 28 Oct, 2015 1 commit
    • Rodrigo Vivi's avatar
      drm/i915/kbl: Introduce Kabylake platform defition. · ef11bdb3
      Rodrigo Vivi authored
      Kabylake is a Intel® Processor containing Intel® HD Graphics
      following Skylake.
      
      It is Gen9p5, so it inherits everything from Skylake.
      
      Let's start by adding the platform separated from Skylake
      but reusing most of all features, functions etc. Later we
      rebase the PCI-ID patch without is_skylake=1
      so we don't replace what original Author did there.
      
      Few IS_SKYLAKEs if statements are not being covered by this patch
      on purpose:
         - Workarounds: Kabylake is derivated from Skylake H0 so no
           		  W/As apply here.
         - GuC: A following patch removes Kabylake support with an
           	  explanation: No firmware available yet.
         - DMC/CSR: Done in a separated patch since we need to be carefull
           	      and load the version for revision 7 since
      	      Kabylake is Skylake H0.
      
      v2: relative cleaner commit message and added the missed
          IS_KABYLAKE to intel_i2c.c as pointed out by Jani.
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      ef11bdb3
  25. 13 Oct, 2015 1 commit
  26. 09 Jun, 2015 1 commit
    • Jani Nikula's avatar
      drm/i915: Fix DDC probe for passive adapters · 3f5f1554
      Jani Nikula authored
      Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
      devices, as they do not have a sink device in them to respond to any AUX
      traffic. When probing these dongles over the DDC, sometimes they will
      NAK the first attempt even though the transaction is valid and they
      support the DDC protocol. The retry loop inside of
      drm_do_probe_ddc_edid() would normally catch this case and try the
      transaction again, resulting in success.
      
      That, however, was thwarted by the fix for [1]:
      
      commit 9292f37e
      Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Date:   Thu Jan 5 09:34:28 2012 -0200
      
          drm: give up on edid retries when i2c bus is not responding
      
      This added code to exit immediately if the return code from the
      i2c_transfer function was -ENXIO in order to reduce the amount of time
      spent in waiting for unresponsive or disconnected devices. That was
      possible because the underlying i2c bit banging algorithm had retries of
      its own (which, of course, were part of the reason for the bug the
      commit fixes).
      
      Since its introduction in
      
      commit f899fc64
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Jul 20 15:44:45 2010 -0700
      
          drm/i915: use GMBUS to manage i2c links
      
      we've been flipping back and forth enabling the GMBUS transfers, but
      we've settled since then. The GMBUS implementation does not do any
      retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
      on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
      the retry on -ENXIO.
      
      Retry GMBUS once on -ENXIO on first message to mitigate the issues with
      passive adapters.
      
      This patch is based on the work, and commit message, by Todd Previte
      <tprevite@gmail.com>.
      
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
      
      v2: Don't retry if using bit banging.
      
      v3: Move retry within gmbux_xfer, retry only on first message.
      
      v4: Initialize GMBUS0 on retry (Ville).
      
      v5: Take index reads into account (Ville).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
      Cc: Todd Previte <tprevite@gmail.com>
      Cc: stable@vger.kernel.org
      Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
      Tested-by: default avatarJim Bride <jim.bride@linux.intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      3f5f1554
  27. 20 May, 2015 2 commits
  28. 23 Apr, 2015 1 commit