1. 09 May, 2016 10 commits
    • Chris Wilson's avatar
      drm/i915: Store a i915 backpointer from engine, and use it · c033666a
      Chris Wilson authored
         text	   data	    bss	    dec	    hex	filename
      6309351	3578714	 696320	10584385	 a18141	vmlinux
      6308391	3578714	 696320	10583425	 a17d81	vmlinux
      
      Almost 1KiB of code reduction.
      
      v2: More s/INTEL_INFO()->gen/INTEL_GEN()/ and IS_GENx() conversions
      
         text	   data	    bss	    dec	    hex	filename
      6304579	3578778	 696320	10579677	 a16edd	vmlinux
      6303427	3578778	 696320	10578525	 a16a5d	vmlinux
      
      Now over 1KiB!
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-3-git-send-email-chris@chris-wilson.co.uk
      c033666a
    • Chris Wilson's avatar
      drm/i915/execlists: Refactor common engine setup · e1382efb
      Chris Wilson authored
      Move all of the constant assignments up front and into a common
      function. This is primarily to ensure the backpointers are set as early
      as possible for later use during initialisation.
      
      v2: Use a constant struct so that all the similar values are set
      together.
      v3: Sanitize the engine's IMR to disable any potential interrupt before
      we are ready (enabled in init_hw).
      v4: Ignore the engine's IMR, to be resolved later
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: Dave Gordon <david.s.gordon@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462545621-30125-2-git-send-email-chris@chris-wilson.co.uk
      e1382efb
    • Tvrtko Ursulin's avatar
      drm/i915: Small display interrupt handlers tidy · 91d14251
      Tvrtko Ursulin authored
      I have noticed some of our interrupt handlers use both dev and
      dev_priv while they could get away with only dev_priv in the
      huge majority of cases.
      
      Tidying that up had a cascading effect on changing functions
      prototypes, so relatively big churn factor, but I think it is
      for the better.
      
      For example even where changes cascade out of i915_irq.c, for
      functions prefixed with intel_, genX_ or <plat>_, it makes more
      sense to take dev_priv directly anyway.
      
      This allows us to eliminate local variables and intermixed usage
      of dev and dev_priv where only one is good enough.
      
      End result is shrinkage of both source and the resulting binary.
      
      i915.ko:
      
       - .text         000b0899
       + .text         000b0619
      
      Or if we look at the Gen8 display irq chain:
      
       -00000000000006ad t gen8_irq_handler
       +0000000000000663 t gen8_irq_handler
         -0000000000000028 T intel_opregion_asle_intr
         +0000000000000024 T intel_opregion_asle_intr
         -000000000000008c t ilk_hpd_irq_handler
         +000000000000007f t ilk_hpd_irq_handler
         -0000000000000116 T intel_check_page_flip
         +0000000000000112 T intel_check_page_flip
         -000000000000011a T intel_prepare_page_flip
         +0000000000000119 T intel_prepare_page_flip
         -0000000000000014 T intel_finish_page_flip_plane
         +0000000000000013 T intel_finish_page_flip_plane
         -0000000000000053 t hsw_pipe_crc_irq_handler
         +000000000000004c t hsw_pipe_crc_irq_handler
         -000000000000022e t cpt_irq_handler
         +0000000000000213 t cpt_irq_handler
      
      So small shrinkage but it is all fast paths so doesn't harm.
      
      Situation is similar in other interrupt handlers as well.
      
      v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      91d14251
    • Ville Syrjälä's avatar
      drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT · d6199256
      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>
      d6199256
    • Ville Syrjälä's avatar
      drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed · b2ccb822
      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>
      b2ccb822
    • Ville Syrjälä's avatar
      drm/i915: Respect DP++ adaptor TMDS clock limit · b1ba124d
      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>
      b1ba124d
    • Ville Syrjälä's avatar
      drm: Add helper for DP++ adaptors · ede53344
      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
      ede53344
    • Maarten Lankhorst's avatar
    • Daniel Vetter's avatar
      Revert "mfd: intel_soc_pmic_core: Terminate panel control GPIO lookup table correctly" · 7ccc70a8
      Daniel Vetter authored
      This reverts commit 3543995a.
      
      I mixed up maintainers and thought Linus' ack was for the mfd tree.
      But Lee Jones (the real maintainer) wants to merge this through the
      mfd tree, so revert here.
      
      Cc: Lee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      7ccc70a8
    • Kenneth Graunke's avatar
      drm/i915: Allow MI_LOAD_REGISTER_REG between whitelisted registers. · 6761d0a1
      Kenneth Graunke authored
      Allowing register copies where the source and destination are both
      whitelisted should be safe, and is useful.  For example, Mesa uses
      this to load the command streamer math registers with data from the
      pipeline statistics counters.
      
      v2: Reject writes to OACONTROL (and reads as well :(
      Signed-off-by: default avatarKenneth Graunke <kenneth@whitecape.org>
      Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1462521014-13595-1-git-send-email-chris@chris-wilson.co.uk
      6761d0a1
  2. 08 May, 2016 1 commit
  3. 05 May, 2016 3 commits
  4. 04 May, 2016 3 commits
  5. 03 May, 2016 5 commits
  6. 02 May, 2016 4 commits
  7. 29 Apr, 2016 14 commits