1. 18 4月, 2013 24 次提交
  2. 09 4月, 2013 4 次提交
  3. 07 4月, 2013 2 次提交
    • B
      drm/i915: PCH_NOP · 40c7ead9
      Ben Widawsky 提交于
      Given certain fusing options discussed in the previous patch, it's
      possible to end up with platforms that normally have PCH but that PCH
      doesn't actually exist. In many cases, this is easily remedied with
      setting 0 pipes. This covers the other corners.
      
      Requiring this is a symptom of improper code splitting (using
      HAS_PCH_SPLIT instead of proper GEN checking, basically). I do not want
      to fix this.
      
      v2: Remove PCH reflck after change in previous patch (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      40c7ead9
    • B
      drm/i915: Support PCH no display · e3c74757
      Ben Widawsky 提交于
      GEN supports a fusing option which subtracts the PCH display (making the
      CPU display also useless). In this configuration MMIO which gets decoded
      to a certain range will hang the CPU.
      
      For us, this is sort of the equivalent of having no pipes, and we can
      easily modify some code to not do certain things with no pipes.
      
      v2: Moved the num pipes check up in the call chain, and removed extra
      checks noted by Daniel. For more details, see:
      http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html
      
      v3: Drop the intel_setup_overlay check (Daniel)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      e3c74757
  4. 06 4月, 2013 7 次提交
  5. 03 4月, 2013 3 次提交
    • D
      drm/i915: create pipe_config->dpll for clock state · f47709a9
      Daniel Vetter 提交于
      Clock computations and handling are highly encoder specific, both in
      the optimal clock selection and also in which clocks to use and when
      sharing of clocks is possible.
      
      So the best place to do this is somewhere in the encoders, with a
      generic fallback for those encoders without special needs. To facility
      this, add a pipe_config->clocks_set boolean.
      
      This patch here is only prep work, it simply sets the computed clock
      values in pipe_config->dpll, and uses that data in the hw clock
      setting functions.
      
      Haswell code isn't touched, simply because Haswell clocks work much
      different and need their own infrastructure (with probably a
      Haswell-specific config->ddi_clock substruct).
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f47709a9
    • D
      drm/i915: hw readout support for ->has_pch_encoders · 88adfff1
      Daniel Vetter 提交于
      Now we can ditch the checks in the Haswell disable code.
      
      v2: add support for Haswell
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      88adfff1
    • D
      drm/i915: add hw state readout/checking for pipe_config · 0e8ffe1b
      Daniel Vetter 提交于
      We need to be able to read out the hw state code for a bunch
      of reasons:
      - Correctly disabling boot-up/resume state.
      - Pure paranoia.
      
      Since not all of the pipe configuration is e.g. relevant for
      fastboot (or at least we can allow some wiggle room in some
      parameters, like the clocks), we need to add a strict_checking
      parameter to intel_pipe_config_compare for fastboot.
      
      For now intel_pipe_config_compare should be fully paranoid and
      check everything that the hw state readout code supports. Which
      for this infrastructure code is nothing.
      
      I've gone a bit overboard with adding 3 get_pipe_config functions:
      The ilk version will differ with the next patch, so it's not too
      onerous.
      
      v2: Don't check the hw config if the pipe is off, since an enabled,
      but dpms off crtc will obviously have tons of difference with the hw
      state.
      Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0e8ffe1b