1. 26 8月, 2015 2 次提交
  2. 14 8月, 2015 2 次提交
  3. 27 7月, 2015 1 次提交
  4. 08 6月, 2015 1 次提交
  5. 22 5月, 2015 3 次提交
  6. 08 5月, 2015 1 次提交
  7. 13 4月, 2015 2 次提交
  8. 01 4月, 2015 3 次提交
  9. 26 3月, 2015 1 次提交
  10. 18 3月, 2015 1 次提交
  11. 27 1月, 2015 5 次提交
    • M
      drm/i915: Add atomic_get_property entrypoint for connectors (v2) · 2545e4a6
      Matt Roper 提交于
      Even though we only support atomic plane updates at the moment, we still
      need to add an .atomic_get_property() entrypoint for connectors before
      we allow the driver to flip on the DRIVER_ATOMIC bit.  As soon as that
      bit gets set, the DRM core will start adding atomic connector properties
      (in addition to the plane properties we care about at the moment), so we
      need to be able to handle the new way the DRM core will interact with
      us.
      
      For simplicity, we just lookup driver-specific connector properties in
      the usual shadow array maintained by the core.  Once we get real atomic
      modeset support for crtc's and planes, this code should be re-written to
      pull the data out of crtc/connector state structures.
      
      v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander)
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2545e4a6
    • M
      drm/i915: Setup dummy atomic state for connectors (v3) · c6f95f27
      Matt Roper 提交于
      We want to enable/test plane updates via the atomic interface, but as
      soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
      codepaths to lookup properties during drmModeGetConnector() and some of
      those codepaths unconditionally dereference connector->state
      (specifically when looking up the CRTC ID property in
      drm_atomic_connector_get_property()).  Create a dummy connector state
      for each connector at init time to ensure the DRM core doesn't try to
      dereference a NULL connector->state.  The actual connector properties
      will never be updated or contain useful information, but since we're
      doing this specifically for testing/debug of the plane operations (and
      only when a specific kernel module option is given), that shouldn't
      really matter.
      
      Once we start creating connector states, the DRM core will want to be
      able to clean them up for us.  We also need to hook up the destruction
      entrypoint to the core's helper.
      
      v2: Squash in the patch to set the state destruction hook (Ander & Bob)
      
      v3: Only create dummy connector states when we're actually faking
          atomic support.  (Ander)
      Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c6f95f27
    • A
      drm/i915: Make intel_crtc->config a pointer · 6e3c9717
      Ander Conselvan de Oliveira 提交于
      To match the semantics of drm_crtc->state, which this will eventually
      become. The allocation of the memory for config will be fixed in a
      followup patch. By adding the extra _config field to intel_crtc it was
      possible to generate this entire patch with the cocci script below.
      
      @@ @@
      struct intel_crtc {
      ...
      -struct intel_crtc_state config;
      +struct intel_crtc_state _config;
      +struct intel_crtc_state *config;
      ...
      }
      @@ struct intel_crtc *crtc; @@
      -memset(&crtc->config, 0, sizeof(crtc->config));
      +memset(crtc->config, 0, sizeof(*crtc->config));
      @@ @@
      __intel_set_mode(...) {
      <...
      -to_intel_crtc(crtc)->config = *pipe_config;
      +(*(to_intel_crtc(crtc)->config)) = *pipe_config;
      ...>
      }
      @@ @@
      intel_crtc_init(...) {
      ...
      WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe);
      +intel_crtc->config = &intel_crtc->_config;
      return;
      ...
      }
      @@ struct intel_crtc *crtc; @@
      -&crtc->config
      +crtc->config
      @@ struct intel_crtc *crtc; identifier member; @@
      -crtc->config.member
      +crtc->config->member
      @@ expression E; @@
      -&(to_intel_crtc(E)->config)
      +to_intel_crtc(E)->config
      @@ expression E; identifier member; @@
      -to_intel_crtc(E)->config.member
      +to_intel_crtc(E)->config->member
      
      v2: Clarify manual changes by splitting them into another patch. (Matt)
          Improve cocci script to generate even more of the changes. (Ander)
      Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6e3c9717
    • A
      drm/i915: Embedded struct drm_crtc_state in intel_crtc_state · 2d112de7
      Ander Conselvan de Oliveira 提交于
      And get rid of the duplicate mode structures. This patch was generated
      with the following semantic patch:
      
      @@ @@
      struct intel_crtc_state {
      +struct drm_crtc_state base;
      +
      ...
      -struct drm_display_mode requested_mode;
      -struct drm_display_mode adjusted_mode;
      ...
      }
      @@ struct intel_crtc_state *state; @@
      -state->adjusted_mode
      +state->base.adjusted_mode
      @@ struct intel_crtc_state *state; @@
      -state->requested_mode
      +state->base.mode
      @@ struct intel_crtc_state state; @@
      -state.adjusted_mode
      +state.base.adjusted_mode
      @@ struct intel_crtc_state state; @@
      -state.requested_mode
      +state.base.mode
      @@ struct drm_crtc *crtc; @@
      -to_intel_crtc(crtc)->config.adjusted_mode
      +to_intel_crtc(crtc)->config.base.adjusted_mode
      @@ identifier member; expression E; @@
      -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E);
      +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E);
      @@ identifier member; @@
      -PIPE_CONF_CHECK_I(adjusted_mode.member);
      +PIPE_CONF_CHECK_I(base.adjusted_mode.member);
      @@ identifier member; @@
      -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member);
      +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member);
      
      v2: Completely generate the patch with cocci. (Ander)
      Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2d112de7
    • A
      drm/i915: Rename struct intel_crtc_config to intel_crtc_state · 5cec258b
      Ander Conselvan de Oliveira 提交于
      The objective is to make this structure usable with the atomic helpers,
      so let's start with the rename. Patch generated with coccinelle:
      
      @@ @@
      -struct intel_crtc_config {
      +struct intel_crtc_state {
      ...
      }
      @@ @@
      -struct intel_crtc_config
      +struct intel_crtc_state
      
      v2: Completely generate the patch with cocci. (Ander)
      Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5cec258b
  12. 13 1月, 2015 1 次提交
  13. 01 11月, 2014 1 次提交
  14. 19 6月, 2014 1 次提交
  15. 11 6月, 2014 1 次提交
    • V
      drm/i915: Avoid div-by-zero when pixel_multiplier is zero · 2b85886a
      Ville Syrjälä 提交于
      On certain platforms pixel_multiplier is read out in
      .get_pipe_config(), but it also gets used to calculate the
      pixel clock in intel_sdvo_get_config(). If the pipe is disable
      but some SDVO outputs are active, we may end up dividing by zero
      in intel_sdvo_get_config().
      
      To avoid the problem simply check for zero pixel_multiplier and skip
      the division. Another attempt at fixing this involved populating
      pixel_multiplier to 1 even for disabled pipes, but that triggered a
      WARN because SDVO_CMD_GET_CLOCK_RATE_MULT command failed and thus
      encoder_pixel_multiplier was left at zero and didn't match
      pipe_config->pixel_multiplier.
      
      The "divide by pixel_multiplier" operation got introduced here:
       commit 18442d08
       Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
       Date:   Fri Sep 13 16:00:08 2013 +0300
      
          drm/i915: Fix port_clock and adjusted_mode.clock readout all over
      
      and it has caused a regression on certain machines since they would
      hit the div-by-zero during resume.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76520
      Cc: <stable@vger.kernel.org> # 3.13+
      Tested-by: NTim Richardson <tim@tim-richardson.net>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      2b85886a
  16. 04 6月, 2014 1 次提交
  17. 16 5月, 2014 3 次提交
  18. 07 5月, 2014 1 次提交
  19. 05 5月, 2014 1 次提交
    • D
      drm/i915/sdvo: Remove ->mode_set callback · 192d47a6
      Daniel Vetter 提交于
      SDVO is used by both crtcs using the i9xx_ and the ironlake_
      functions. For both cases there is nothing between the
      encoder->mode_set and the encoder->pre_enable calls that touches the
      hardware.
      
      The vlv_ functions are different since they enable the pll before the
      ->pre_enable hook. But SDVO isn't supported on vlv platforms, so this
      doesn't matter.
      
      We've also already clean up all the sdvo state computation logic, all
      relevant parts are already in the ->compute_config hook.  So we can
      just get rid of the ->mode_set hook by converting it to a ->pre_enable
      hook.
      Reviewed-by: NImre Deak <imre.deak@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      192d47a6
  20. 16 4月, 2014 1 次提交
  21. 21 3月, 2014 1 次提交
  22. 11 3月, 2014 1 次提交
    • V
      drm/i915: Make encoder cloning more flexible · bc079e8b
      Ville Syrjälä 提交于
      Currently we allow encoders to indicate whether they can be part of a
      cloned set with just one flag. That's not flexible enough to describe
      the actual hardware capabilities. Instead make it a bitmask of encoder
      types with which the current encoder can be cloned.
      
      For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
      match what the old boolean flag allowed. We will add some more cloning
      options in the future.
      
      Note that this patch also removes the encoder.possible_clones setting
      from encoder setup code - we compute this dynamically.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      [danvet: Add Ville's explanation why removing the encoder
      possible_clones is save.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bc079e8b
  23. 14 2月, 2014 3 次提交
  24. 10 12月, 2013 1 次提交
  25. 28 11月, 2013 1 次提交