Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Daniel writes:
Since I expect Linus to open the merge window in about a week I guess this
is the last i915 feature pull for 3.10. Highlights:
Updated testing tree for -next. Highlights:
- Corner case fixes discovered with static analyzers (Damien).
- More fixes to combat unclaimed register errors on Haswell (Paulo).
- Some small fixes to the gpu turbo code (Rodrigo+Ben), Ben has more
  fixes for overclocking support pending.
- More prep work for fastboot from Chris.
- VT-switchless suspend/resume from Jesse.
- The prep work of Egbert Eich's hpd irq storm handling. Hopefully we can
  squeeze in the actual storm handling code for 3.10 ...
- More convenience helpers for Imre's sg iterator. Core parts acked by
  Andrew Morton.
- A bit of backlight code cleanup from Jani.
- Fixed ilk gpu reset (Jesse).
- Reduced color range handling fixes for VLV (Ville).

The big item here is though the introduction of pipe_config to properly
pre-compute the desired modeset state before touching the hw. Together
with some very basic support to read out the current config from the hw
and compare the state with the sw tracking. This is all prep work for more
reliable fastboot, atomic modesets and other cool features. Stuff
converted to the new world includes:
- Most simple pipe attributes (reduce color range, pixel multiplier).
- Pipe bpp/dither handling.
- Some convenience flags like ->has_pch_encoder to simplify the code flow.
- (Almost) DP clock handling, had to be reverted since part of a prep
  patch was lost in rebasing ...
Expect a lot of patches for this throughout 3.11, there's tons of work
till we have all state properly tracked for fastbooting to woExpect a lot
of patches for this throughout 3.11, there's tons of work till we have all
state properly tracked for fastbooting to work.

For 3.10 I have a bunch of fixes queued up and I plan to send them all out
at the end of this week. I need to shuffle patches in my -next queue a bit
so that we don't but feature-y stuff in there, too. The main thing I'd
like to sneak in is Egbert's hpd irq storm handling, which should be
pretty low-risk since all the infrastructure work has landed already. I
also have the oops fix pending, but that only mustered review before the
w/e and giving how hairy that part of our modeset code is, I want to give
it some more testing before forwarding.

Note: annarchy.fd.o seems to run out of disk space, so couldn't push the
usual for-airlied branch. Tag should work though.

Note 2: I've had to do a backmerge since conflicts grew too ugly, but the
upstream -rc I've backmerged is already in your drm-next.

* tag 'drm-intel-next-2013-04-06' of git://people.freedesktop.org/~danvet/drm-intel: (75 commits)
  drm/i915: info level for simulated gpu hang dmesg notice
  drm/i915: revert eDP bpp clamping code changes
  Revert "drm/i915: fix DP get_hw_state return value"
  drm/i915: Don't use the HDMI port color range bit on Valleyview
  drm/i915: Set PIPECONF color range bit on Valleyview
  drm/i915: extract i9xx_set_pipeconf
  drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900
  drm/i915: create pipe_config->dpll for clock state
  drm/i915: hw readout support for ->has_pch_encoders
  drm/i915: add hw state readout/checking for pipe_config
  drm/i915: rip out superflous is_dp&is_cpu_edp tracking
  drm/i915: remove leaky eDP functions
  drm/i915: track dp target_clock in pipe_config
  drm/i915: move dp_m_n computation to dp_encoder->compute_config
  drm/i915: clear up the fdi/dp set_m_n confusion
  drm/i915: Fix sdvo connector get_hw_state function
  drm/i915: drop DPFLIPSTAT enables on VLV v3
  drm/i915: add Punit read/write routines for VLV v2
  drm/i915: panel power sequencing for VLV eDP v2
  drm/i915/dp: fix up VLV DP handling v2
  ...

Signed-off-by: Alon Levy <alevy@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Rather than building a config which may or may not work, let the driver
build an initial fb config.  This allows the driver to use the BIOS boot
configuration for example, displaying kernel messages and the initial fb
console on the same outputs the BIOS lit up at boot time.  If that
fails, the driver can still fall back the same way as the core.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Spotted by Rob Clark.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.

I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.

Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...

v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
  Dave Airlie didn't want me to kill this one from the fb helper
  interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
  from the driver's ->fb_probe callback to setup the fbdev info
  structure.
- Clarify what the ->fb_probe callback should all do - it needs to
  setup both the fbdev info and allocate the drm framebuffer used as
  backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
  vfunc.

v3: Implement clarifications Laurent Pinchart suggested in his review.

v4: Fix another mispelling Laurent spotted.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.

Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).

But that's both better done in separate patches.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

crtc_id is set but never used, so remove it from struct
drm_fb_helper_crtc.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>