[PATCH 00/19] [RFC] introduce struct intel_pipe_config

[Daniel Vetter <daniel.vetter@ffwll.ch>]

Hi all

So this is my old attempt to push our modeset infrastructure a bit further,
rebased on top of latest dinq. Originally I wanted to push this a bit further
still before submitting for rfc, but with fastboot picking up I think it's
better to throw it out there now.

Roughly this adds a new intel_pipe_config struct which will (eventually) contain
all the configuration parameters of an output pipe. With this I aim to solve a
bunch of issues with the current code:

- We have a lot of encoder/output specific logic in our crtc code. Having a
  struct to conveniently store flags and other special cases allows us to move
  that logic into encoder callbacks. A few examples are bpp selection/dithering,
  limited range selection, pixel clock computations, ... To have a few examples,
  this series converts all users of the mode->flag and the bpp selection.

- Shared resources are currently not checked or only after we've started to
  change the hw state already. Examples are shared plls, shared fdi b/c lanes,
  but also memory bw (we don't bother about this yet) and similar stuff. If the
  code is restructured to compute the pipe config first and only then start
  touching the hw, we can fix this. Fixing this is a requirement to get a
  possible "check mode" of atomic modesetting working correctly.

- Intermingling of configuration selection and hw setup leads to inflexible
  code. Best example is probably the bpp selection - some of the constraints
  like fdi link bw are computed way too late, after e.g. the DP output has
  computed link clock values already. So we can't adjust it any more and are
  left with the only option to fail the modeset.

  Originally I've wanted to implement better handling of fdi b/c 2 lane
  configurations as a proof-of-concept of this, hence just rfc. I'll try to
  amend this over the next few days.

- Lacking infrastructure for fastboot hw state readout. I'm firmly of the
  opinion that if we want fastboot to work on all the insane configuraions out
  there, we need really solid hw state readout support. Hence this series also
  adds pipe_config readout support and starts with some very minimal support for
  comparing different such states.

Comments, flames and ideas for the patches themselves, but also for the above
issues in general highly welcome.

Cheers, Daniel

Daniel Vetter (19):
  drm/i915: introduce struct intel_crtc_config
  drm/i915: compute pipe_config earlier
  drm/i915: add pipe_config->timings_set
  drm/i915: add pipe_config->pixel_multiplier
  drm/i915: add pipe_config->has_pch_encoder
  drm/i915: clear up the fdi/dp set_m_n confusion
  drm/i915: move pipe bpp computation to pipe_config
  drm/i915: clean up plane bpp confusion
  drm/i915: clean up pipe bpp confusion
  drm/i915: move dp_m_n computation to dp_encoder->compute_config
  drm/i915: track dp target_clock in pipe_config
  drm/i915: rip out superflous is_dp&is_cpu_edp tracking
  drm/i915: add hw state readout/checking for pipe_config
  drm/i915: hw readout support for ->has_pch_encoders
  drm/i915: gen2 has no tv out support
  drm/i915: create pipe_config->dpll for clock state
  drm/i915: move dp clock computations to encoder->compute_config
  drm/i915: add pipe_config->limited_color_range
  drm/i915: use pipe_config for lvds dithering

 drivers/gpu/drm/i915/i915_drv.h      |   9 +-
 drivers/gpu/drm/i915/intel_crt.c     |  12 +-
 drivers/gpu/drm/i915/intel_ddi.c     |  27 +-
 drivers/gpu/drm/i915/intel_display.c | 975 ++++++++++++++++-------------------
 drivers/gpu/drm/i915/intel_dp.c      | 231 ++++-----
 drivers/gpu/drm/i915/intel_drv.h     | 106 ++--
 drivers/gpu/drm/i915/intel_hdmi.c    |  35 +-
 drivers/gpu/drm/i915/intel_lvds.c    |  36 +-
 drivers/gpu/drm/i915/intel_sdvo.c    |  50 +-
 drivers/gpu/drm/i915/intel_tv.c      |  14 +-
 10 files changed, 730 insertions(+), 765 deletions(-)

-- 
1.7.11.7