1. 05 4月, 2016 1 次提交
  2. 02 4月, 2016 1 次提交
    • V
      drm/i915: Implement WaPixelRepeatModeFixForC0:chv · c231775c
      Ville Syrjälä 提交于
      DPLL_MD(PIPE_C) is AWOL on CHV. Instead of fixing it someone added
      chicken bits to propagate the pixel multiplier from DPLL_MD(PIPE_B)
      to either pipe B or C. So do that to make pixel repeat work on pipes
      B and C. Pipe A is fine without any tricks.
      
      Fortunately the pixel repeat propagation appears to be a oneshot
      operation, so once the value has been written we can clear the
      chicken bits. So it is still possible to drive pipe B and C with
      different pixel multipliers simultaneosly.
      
      Looks like DPLL_VGA_MODE_DIS must also be set in DPLL(PIPE_B)
      for this to work. But since we keep that bit always set in all
      DPLLs there's no problem.
      
      This of course means we can't reliably read out the pixel multiplier
      for pipes B and C. That would make the state checker unhappy, so I
      added shadow copies of those registers in to dev_priv. The other
      option would have been to skip pixel multiplier, dpll_md an dotclock
      checks entirely on CHV, but that feels like a serious loss of cross
      checking, so just pretending that we have working DPLL MD registers
      seemed better. Obviously with the shadow copies we can't detect if
      the pixel multiplier was properly configured, nor can we take over
      its state from the BIOS, but hopefully people won't have displays
      that would be limitd to such crappy modes.
      
      There is one strange flicker still remaining. It's visible on
      pipe C/HDMID when HDMIB is enabled while driven by pipe B.
      It doesn't occur if pipe A drives HDMIB, nor is there any glitch
      on pipe B/HDMIB when port C/HDMID starts up. I don't have a board
      with HDMIC so not sure if it happens there too. So I'm not sure
      if it's somehow tied in with this strange linkage between pipe B
      and C. Sadly I was unable to find an enable sequence that would
      avoid the glitch, but at least it's not fatal ie. the output
      recovers afterwards.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1458052809-23426-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
      c231775c
  3. 31 3月, 2016 3 次提交
  4. 30 3月, 2016 1 次提交
  5. 29 3月, 2016 4 次提交
  6. 24 3月, 2016 2 次提交
  7. 23 3月, 2016 1 次提交
  8. 22 3月, 2016 4 次提交
  9. 21 3月, 2016 2 次提交
  10. 18 3月, 2016 2 次提交
  11. 17 3月, 2016 10 次提交
  12. 16 3月, 2016 4 次提交
  13. 14 3月, 2016 1 次提交
  14. 09 3月, 2016 2 次提交
  15. 04 3月, 2016 1 次提交
    • V
      drm/i915: Store rawclk_freq in dev_priv · e7dc33f3
      Ville Syrjälä 提交于
      Generalize rawclk handling by storing it in dev_priv.
      
      Presumably our hrawclk readout works at least for CTG and ELK
      since we've been using it for DP AUX on those platforms. There
      are no real docs anymore after configdb vanished, so the only
      reference is the public CTG GMCH spec. What bits are listed in
      that doc match our code. The ELK GMCH spec have no relevant
      details unfortunately.
      
      The PNV situation is less clear. Starting from
      commit aa17cdb4 ("drm/i915: initialize backlight max from VBT")
      we assume that the CTG/ELK hrawclk readout works for PNV as well.
      At least the results *seem* reasonable for one PNV machine (Lenovo
      Ideapad S10-3t). Sadly the PNV GMCH spec doesn't have the goods on
      the relevant register either.
      
      So let's keep assuming it works for PNV,ELK,CTG and read it out on
      those platforms. G33 also has hrawclk according to some notes
      in BSpec, but we don't actually need it for anything, so let's not
      even try to read it out there.
      
      v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split
          Use KHz() all over, and kill off a few useless temp variables
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
      e7dc33f3
  16. 03 3月, 2016 1 次提交