1. 14 2月, 2013 1 次提交
  2. 25 1月, 2013 1 次提交
  3. 20 1月, 2013 3 次提交
    • V
      drm/i915: Provide the quantization range in the AVI infoframe · abedc077
      Ville Syrjälä 提交于
      The AVI infoframe is able to inform the display whether the source is
      sending full or limited range RGB data.
      
      As per CEA-861 [1] we must first check whether the display reports the
      quantization range as selectable, and if so we can set the approriate
      bits in the AVI inforframe.
      
      [1] CEA-861-E - 6.4 Format of Version 2 AVI InfoFrame
      
      v2: Give the Q bits better names, add spec chapter information
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      abedc077
    • V
      drm/i915: Add "Automatic" mode for the "Broadcast RGB" property · 55bc60db
      Ville Syrjälä 提交于
      Add a new "Automatic" mode to the "Broadcast RGB" range property.
      When selected the driver automagically selects between full range and
      limited range output.
      
      Based on CEA-861 [1] guidelines, limited range output is selected if the
      mode is a CEA mode, except 640x480. Otherwise full range output is used.
      Additionally DVI monitors should most likely default to full range
      always.
      
      As per DP1.2a [2] DisplayPort should always use full range for 18bpp, and
      otherwise will follow CEA-861 rules.
      
      NOTE: The default value for the property will now be "Automatic"
      so some people may be affected in case they're relying on the
      current full range default.
      
      [1] CEA-861-E - 5.1 Default Encoding Parameters
      [2] VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
      
      v2: Use has_hdmi_sink to check if a HDMI monitor is present
      v3: Add information about relevant spec chapters
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      55bc60db
    • V
      drm/i915: Fix RGB color range property for PCH platforms · 3685a8f3
      Ville Syrjälä 提交于
      The RGB color range select bit on the DP/SDVO/HDMI registers
      disappeared when PCH was introduced, and instead a new PIPECONF bit
      was added that performs the same function.
      
      Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
      it in the encoder mode_fixup if limited color range is requested.
      Set the the PIPECONF bit 13 based on the flag.
      
      Experimentation showed that simply toggling the bit while the pipe is
      active doesn't work. We need to restart the pipe, which luckily already
      happens.
      
      The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
      although it doesn't seem to do any harm in practice.
      
      TODO:
      - the PIPECONF bit too seems to have disappeared from HSW. Need a
        volunteer to test if it's just a documentation issue or if it's really
        gone. If the bit is gone and no easy replacement is found, then I suppose
        we may need to use the pipe CSC unit to perform the range compression.
      
      v2: Use mode private_flags instead of intel_encoder virtual functions
      v3: Moved the intel_dp color_range handling after bpc check to help
          later patches
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3685a8f3
  4. 21 12月, 2012 1 次提交
  5. 14 12月, 2012 1 次提交
  6. 29 11月, 2012 2 次提交
  7. 22 11月, 2012 1 次提交
  8. 12 11月, 2012 7 次提交
  9. 10 10月, 2012 1 次提交
    • P
      drm/i915: completely rewrite the Haswell PLL handling code · 6441ab5f
      Paulo Zanoni 提交于
      Problems with the previous code:
        - HDMI just uses WRPLL1 for everything, so dual head cases might not
          work sometimes.
        - At encoder->mode_set we just write the PLL register without doing
          any kind of check (e.g., check if the PLL is already being used).
        - There is no way to fail and return error codes at
          encoder->mode_set.
        - We write to PORT_CLK_SEL at mode_set and we never disable it.
        - Machines hang due to wrong clock enable/disable sequence.
      
      So here we rewrite the code, making it a little more like the
      pre-Haswell PLL mode set code:
        - Check PLL availability at ironlake_crtc_mode_set.
        - Try to use both WRPLLs.
        - Check if PLLs are used before actually trying to use them, and
          properly fail with error messages.
        - Enable/disable PORT_CLK_SEL at the right place.
        - Add some WARNs to check for bugs.
      
      The next improvement will be to try to reuse PLLs if the timings
      match, but this is content for another patch and it's already
      documented with a TODO comment.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6441ab5f
  10. 03 10月, 2012 2 次提交
  11. 26 9月, 2012 1 次提交
    • P
      drm/i915: make sure we write all the DIP data bytes · adf00b26
      Paulo Zanoni 提交于
      ... even if the actual infoframe is smaller than the maximum possible
      size.
      
      If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
      be correctly calculated in some cases (e.g., when changing the port),
      and this will lead to black screens on HDMI monitors. The ECC value is
      generated by the hardware.
      
      I don't see how this should break anything since we're writing 0 and
      that should be the correct value, so this patch should be safe.
      
      Notice that on IVB and older we actually have 64 bytes available for
      VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
      others are either read-only ECC values or marked as "reserved". On HSW
      we only have 32 bytes, and the ECC value is stored on its own separate
      read-only register. See BSpec.
      
      This patch fixes bug #46761, which is marked as a regression
      introduced by commit 4e89ee17:
          drm/i915: set the DIP port on ibx_write_infoframe
      
      Before commit 4e89 we were just failing to send AVI infoframes when we
      needed to change the port, which can lead to black screens in some
      cases. After commit 4e89 we started sending infoframes, but with a
      possibly wrong ECC value. After this patch I hope we start sending
      correct infoframes.
      
      Version 2:
        - Improve commit message
        - Try to make the code more clear
      
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      adf00b26
  12. 24 9月, 2012 1 次提交
  13. 20 9月, 2012 1 次提交
    • W
      drm/i915: HDMI - Clear Audio Enable bit for Hot Plug unconditionally · 3cce574f
      Wang Xingchao 提交于
      Clear Audio Enable bit to trigger unsolicated event to notify Audio
      Driver part the HDMI hot plug change. The patch fixed the bug when
      remove HDMI cable the bit was not cleared correctly.
      
      In intel_enable_hdmi(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
      be set to trigger unsolicated event to notify Alsa driver the change.
      
      intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
      remove the hdmi cable, here's debug log:
      
      [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
      [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
      
      so when comes back to intel_disable_hdmi(), the "Audio enable bit" will not be cleared. And this
      cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
      
      This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
      
      [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
      [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
      Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3cce574f
  14. 17 9月, 2012 1 次提交
    • W
      drm/i915: HDMI - Clear Audio Enable bit for Hot Plug · b98b6016
      Wang Xingchao 提交于
      Clear Audio Enable bit to trigger unsolicated event to notify Audio
      Driver part the HDMI hot plug change. The patch fixed the bug when
      remove HDMI cable the bit was not cleared correctly.
      
      In intel_hdmi_dpms(), if intel_hdmi->has_audio been true, the "Audio enable bit" will
      be set to trigger unsolicated event to notify Alsa driver the change.
      
      intel_hdmi->has_audio will be reset to false from intel_hdmi_detect() after
      remove the hdmi cable, here's debug log:
      
      [  187.494153] [drm:output_poll_execute], [CONNECTOR:17:HDMI-A-1] status updated from 1 to 2
      [  187.525349] [drm:intel_hdmi_detect], HDMI: has_audio = 0
      
      so when comes back to intel_hdmi_dpms(), the "Audio enable bit" will not be cleared. And this
      cause the eld infomation and pin presence doesnot update accordingly in alsa driver side.
      
      This patch will also trigger unsolicated event to alsa driver to notify the hot plug event:
      
      [  187.853159] ALSA sound/pci/hda/patch_hdmi.c:772 HDMI hot plug event: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=1
      [  187.853268] ALSA sound/pci/hda/patch_hdmi.c:990 HDMI status: Codec=3 Pin=5 Presence_Detect=0 ELD_Valid=0
      Signed-off-by: NWang Xingchao <xingchao.wang@intel.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b98b6016
  15. 06 9月, 2012 5 次提交
    • D
      drm/i915: s/intel_encoder_disable/intel_encoder_noop · 1f703855
      Daniel Vetter 提交于
      Because that's what it is. Unfortunately we can't rip this out because
      the fb helper has an incetious relationship with the crtc helper - it
      likes to call disable_unused_functions, among other things.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      1f703855
    • D
      85234cdc
    • D
      drm/i915: rip out encoder->prepare/commit · c9deac97
      Daniel Vetter 提交于
      With the new infrastructure we're doing this when enabling/disabling
      the entire display pipe.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c9deac97
    • D
      drm/i915: copy&paste drm_crtc_helper_set_mode · a6778b3c
      Daniel Vetter 提交于
      Together with the static helper functions drm_crtc_prepare_encoders
      and drm_encoder_disable (which will be simplified in the next patch,
      but for now are 1:1 copies). Again, no changes beside new names for
      these functions.
      
      Also call our new set_mode instead of the crtc helper one now in all
      the places we've done so far.
      
      v2: Call the function just intel_set_mode to better differentia it
      from intel_crtc_mode_set which really only does the ->mode_set step of
      the entire modeset sequence on one crtc. Whereas this function does
      the global change.
      Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a6778b3c
    • D
      drm/i915/hdmi: convert to encoder->disable/enable · 5ab432ef
      Daniel Vetter 提交于
      I've picked hdmi as the first encoder to convert because it's rather
      simple:
      - no cloning possible
      - no differences between prepare/commit and dpms off/on switching.
      
      A few changes are required to do so:
      - Split up the dpms code into an enable/disable function and wire it
        up with the intel encoder.
      - Noop out the existing encoder prepare/commit functions used by the
        crtc helper - our crtc enable/disable code now calls back into the
        encoder enable/disable code at the right spot.
      - Create new helper functions to handle dpms changes.
      - Add intel_encoder->connectors_active to better track dpms state. Atm
        this is unused, but it will be useful to correctly disable the
        entire display pipe for cloned configurations. Also note that for
        now this is only useful in the dpms code - thanks to the crtc
        helper's dpms confusion across a modeset operation we can't (yet)
        rely on this having a sensible value in all circumstances.
      - Rip out the encoder helper dpms callback, if this is still getting
        called somewhere we have a bug. The slight issue with that is that
        the crtc helper abuses dpms off to disable unused functions. Hence
        we also need to implement a default encoder disable function to do
        just that with the new encoder->disable callback.
      - Note that we drop the cpt modeset verification in the commit
        callback, too. The right place to do this would be in the crtc's
        enable function, _after_ all the encoders are set up. But because
        not all encoders are converted yet, we can't do that. Hence disable
        this check temporarily as a minor concession to bisectability.
      
      v2: Squash the dpms mode to only the supported values -
      connector->dpms is for internal tracking only, we can hence avoid
      needless state-changes a bit whithout causing harm.
      
      v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5ab432ef
  16. 24 8月, 2012 1 次提交
  17. 26 7月, 2012 2 次提交
    • D
      drm/i915: add port parameter to intel_hdmi_init · 08d644ad
      Daniel Vetter 提交于
      Instead of having a giant if cascade to figure this out according to
      the passed-in register. We could do quite a bit more cleaning up and
      all by using the port at more places, but I think this should be part
      of a bigger rework to introduce a struct intel_digital_port which
      would keep track of all these things. I guess this will be part of
      some haswell-DP-induced refactoring.
      
      For now this rips out the big cascade, which is what annoyed me so
      much.
      
      v2: Add port variable name back for the func decl (I've tried to trick
      myself below the 80 char limit).
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      08d644ad
    • D
      drm/i915: simplify possible_clones computation · 66a9278e
      Daniel Vetter 提交于
      Intel hw only has one MUX for encoders, so outputs are either not
      cloneable or all in the same group of cloneable outputs. This neatly
      simplifies the code and allows us to ditch some ugly if cascades in
      the dp and hdmi init code (well, we need these if cascades for other
      stuff still, but that can be taken care of in follow-up patches).
      
      Note that this changes two things:
      - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is
        gen3+, so no problem. Note that the old code had a bug and didn't
        allow cloning crt with dvo (but only the other way round).
      - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't
        work, but the only reason I've found is that you can't use the
        panel-fitter (used for lvds upscaling) with anything else. But we
        don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is
        a) rather confusing b) mostly as a guideline to implementors (i.e.
        explicitly stating what is already implicit from the spec, without
        always going into the details of why). So I think we can ignore this
        - worst case we'll get a bug report from a user with with sdvo-lvds
        and sdvo-tmds and have to add that special case back in.
      
      Because sdvo lvds is a bit special explain in comments why sdvo LVDS
      outputs can be cloned, but native LVDS and eDP can't be cloned - we
      use the panel fitter for the later, but not for sdvo.
      
      Note that this also uncoditionally initializes the panel_vdd work used
      by eDP. Trying to be clever doesn't buy us anything (but strange bugs)
      and this way we can kill the is_edp check.
      
      v2: Incorporate review from Paulo
      - Add in a missing space.
      - Pimp comment message to address his concerns.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      66a9278e
  18. 20 7月, 2012 1 次提交
  19. 13 6月, 2012 1 次提交
  20. 06 6月, 2012 1 次提交
    • D
      drm/i915: implement IBX hdmi transcoder select workaround · 7a87c289
      Daniel Vetter 提交于
      Bspec Vol 3, Part 3, Section 3.8.1.1, bit 30:
      
      "[DevIBX] Writing to this bit only takes effect when port is enabled.
      Due to hardware issue it is required that this bit be cleared when port
      is disabled. To clear this bit software must temporarily enable this
      port on transcoder A."
      
      Unfortunately the public Bspec misses totally out on the same language
      for HDMIB. Internal Bspec also mentions that one of the bad
      side-effects is that DPx can fail to light up on transcoder A if HDMIx
      is disabled but using transcoder B.
      
      I've found this while reviewing Bsepc. We already implement the same
      workaround for the DP ports.
      
      Also replace a magic 1 with PIPE_B I've found while looking through the
      code.
      
      v2: Implement suggestions from Chris Wilson:
      - add pipe variable to cut down on code noise
      - write the reg value twice to w/a hw issues (Bspec is unclear on
        which bit actually require the write twice stuff, but better be
        paranoid about it)
      - untangle the if logic
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7a87c289
  21. 31 5月, 2012 5 次提交
    • P
      drm/i915: add some barriers when changing DIPs · 9d9740f0
      Paulo Zanoni 提交于
      On IVB and older, we basically have two registers: the control and the
      data register. We write a few consecutitve times to the control
      register, and we need these writes to arrive exactly in the specified
      order.
      
      Also, when we're changing the data register, we need to guarantee that
      anything written to the control register already arrived (since
      changing the control register can change where the data register
      points to). Also, we need to make sure all the writes to the data
      register happen exactly in the specified order, and we also *can't*
      read the data register during this process, since reading and/or
      writing it will change the place it points to.
      
      So invoke the "better safe than sorry" rule and just be careful and
      put barriers everywhere :)
      
      On HSW we still have a control register that we write many times, but
      we have many data registers.
      Demanded-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9d9740f0
    • P
      drm/i915: remove comment about HSW HDMI DIPs · c30b6110
      Paulo Zanoni 提交于
      HSW support is now just like all the other generations: we send AVI
      and SPD InfoFrames. There are other DIPs for HSW, but there are other
      DIPs for the previous generations too. For each gen, we can see which
      DIPs are missing by looking at the 'set_infoframes' function: we
      explicitly disable the DIPs we're not using.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c30b6110
    • P
      drm/i915: don't set SDVO_BORDER_ENABLE when we're HDMI · b659c3db
      Paulo Zanoni 提交于
      The register that controls the HDMI port can be used to control the
      sDVO port. Some bits are defined only for sDVO, and SDVO_BORDER_ENABLE
      is one of those: HDMI ports that can't be used in sDVO mode don't even
      have this bit defined in their specifications.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b659c3db
    • P
      drm/i915: don't write 0 to DIP control at HDMI init · 9d32d165
      Paulo Zanoni 提交于
      At this time, the HDMI port is enabled, and the DIP control register
      specification says we need to disable the port *before* disabling the
      DIPs. Also, while doing this we risk telling the HW to send the AVI
      DIPs once (not every VSync), which really seems to confuse the HW and
      trigger bugs where the DIPs are not sent.
      
      This code was here just to set the DIP register to a 'known state'
      before using it, but since now the set_infoframes functions already
      set the control registers to a known state, this code can go away.
      
      Also, the previous code disables *all* the DIP registers for *each*
      HDMI port, so we end disabling each DIP register more than once.
      
      This patch solves a problem I can reproduce on my IVB machine. When I
      boot it with just a single HDMI monitor, the AVI InfoFrames are not
      sent. With this patch, the InfoFrames are sent. Previously, I wrote a
      patch to 'touch the DIP registers after we enable the HDMI port' to
      solve this same problem, but that patch doesn't seem to be needed
      anymore after this patch.
      
      All this patch does is revert a chunk of the following commit:
      
          commit 64a8fc01
          Author: Jesse Barnes <jbarnes@virtuousgeek.org>
          Date:   Thu Sep 22 11:16:00 2011 +0530
      
              drm/i915: fix ILK+ infoframe support
      
      So bugs that can be bisected to that commit may be fixed now.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43256Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9d32d165
    • P
      drm/i915: disable DIP while changing the port · 72b78c9d
      Paulo Zanoni 提交于
      The register specification says we need to do this.
      
      V2: Only write the register if the port is enabled.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      72b78c9d
新手
引导
客服 返回
顶部