Calculation is a little different than other platforms.

v2: update to use port_clock instead
    rebase on top of Ville's changes
v3: update to new port_clock semantics - don't divide by
    pixel_multiplier (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=67345Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These functions were added before the final PC8 implementation, and
their callers moved to intel_display.c during the code review.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By moving them to intel_fb.c.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And move it so it doesn't need a forward declaration.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also move it to the top of the file so we can remove the forward
declaration.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Flat out skip anything to do with PLL if we have a DSI encoder (and thus
DSI PLL). Also skip PLL computation if the encoder has already set
clocks. This allows for some tidying up of the code, including a
superfluous call to intel_limit() for LVDS downclock path.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we
must get the pixel clock from port_clock in intel_crtc_mode_get().

This bug caused Chris's 845g machine to lockup during boot, and it
was introduced in:

 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

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69713Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already restore planes during the modeset operation, so no need to do
another loop over the planes and try to restore them again.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The VGA plane needs to be disabled before we start doing any
modeset operations on resume.

This should also guarantee that the power well will be enabled
when we call i915_redisable_vga() since it gets explicitly powered on
during resume, and will get powered back off during the modeset
operation if no longer needed.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And the gratious overallocation of crtcs. Seems to go back to the ums
days of yonder ...

We also still need it to make the fbdev emulation happy, but I don't
think there's really a need. Especially since the current fbdev
emulation doesn't actually support cloning.

v2: Use sizeof(*pointer) pattern (Jani).

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No buffer overflows here, but better safe than sorry.

v2:
- Fixup the sizeof conversion, I've missed the pointer deref (Jani).
- Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani).
- Use kmalloc_array for the execbuf fastpath to avoid the memset
  (Chris). I've opted to leave all other conversions as-is since they
  aren't in a fastpath and dealing with cleared memory instead of
  random garbage is just generally nicer.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Drop the contentious kmalloc_array hunk in execbuf.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Done while reviewing all our allocations for fubar. Also a few errant
cases of lacking () for the sizeof operator - just a bit of OCD.

I've left out all the conversions that also should use kcalloc from
this patch  (it's only 2).
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This regression has been introduced in

commit 9f11a9e4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Jun 13 00:54:58 2013 +0200

    drm/i915: set up PIPECONF explicitly for i9xx/vlv platforms

Ville brough up the idea that this is just the pipe A quirk gone
wrong.

Note that after resume the bios might or might not have enabled pipe A
already.  We have a bit of magic to make sure that on resume we set up
a decent mode for pipe A, but I fear if I just smash pipe A to always
on we'd enable it in a bogus state and hang the hw. Hence the
readback.

v2: Clarify the logic a bit as suggested by Chris. Also amend the
commit message to clarify why we don't unconditionally enable the
pipe.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66462
References: https://lkml.org/lkml/2013/8/26/238
Cc: Meelis Roos <mroos@ut.ee>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Use |= instead of = as suggested by Chris.]
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is plenty of evidence suggesting all of the GM45 based Acer
laptops (including their eMachines and Packard Bell brands) use inverted
backlight PWM. Assume this is really the case, and quirk them all.

The old bugs that were fixed by subsystem device specific quirks:
 * https://bugs.freedesktop.org/show_bug.cgi?id=59628
 * https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
 * https://bugs.freedesktop.org/show_bug.cgi?id=44156
 * https://bugzilla.kernel.org/show_bug.cgi?id=53881

See also this bug and the plethora of duplicates:
 * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765438

References: https://bugzilla.kernel.org/show_bug.cgi?id=54171Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The init and resume codepaths want to handel the power well in slightly
different ways, so pull the power well init out from
intel_modeset_init_hw() which gets called in both cases.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make sure we write to IPS before we actually wait.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I always get royally confused how a modeline with all zeros could
possible pass the paranoid pipe config checker. Until I realize again
that we only check the crtc timings. So dump the crtc timings for the
adjusted mode.

This will be even more important for 3D support where the crtc timings
are markedly different from the input modeline if we have
frame-by-frame 3d output enabled.

Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

You can't write it using the MCHBAR mirror, the write will just get
dropped.

This should make us BSpec-compliant, but there's no real bug I could
reproduce that is fixed by this patch.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Fix spelling mistake in the comment that Damien spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.

v2: Move the crtc active checks to intel_crtc_cursor_{set,move} to
    avoid confusing people during modeset

Cc: stable@vger.kernel.org
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The cursor is disabled before crtc mode set in crtc disable (and we
assert this is the case), and enabled afterwards in crtc enable. Do not
update it in crtc mode set.

On HSW enabling a plane on a disabled pipe may hang the entire system.
And there's no good reason for doing it ever, so just don't.

v2: Add note about HSW hangs - vsyrjala

Cc: stable@vger.kernel.org
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Double wide mode is only available on pipe A, except on GDG where
pipe B is also double wide capable.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pipe horizontal source size must be even when either LVDS dual channel
mode, DVO ganged mode, or pipe double wide mode is used.

We must round it down since we can never increase the user specified
viewport size.

The actual error from an odd pipe source width looks like a diagonal
shift, like you might get from a bad stride.

v2: s/ganaged/ganged/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't want to try to push the hardware beyond it's capabilities,
so check the pixel clock against the display core clock limit. Do
it for pre-gen4 for now since that's where we alread have the double
wide pixel clock limit check.

Let's assume that when double wide mode is enabled the max
pixel clock limit is also doubled.

FIXME: panel fitter downscaling probably affects the limit on
non-pch platforms too, so we'd need another version of
ilk_pipe_pixel_rate() to figure that out.

FIXME: should check the limits on all platforms. Also sprites
affect the max allowed pixel rate on some platforms, so we need
to eventually tie all the planes and pipes into one check in
the future. But we need plane state pre-compute before that can
happen.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Read the double wide pipe information from hardware in
i9xx_get_pipe_config(), and check it in intel_pipe_config_compare()

For gen4+ double_wide is always false so the comparison can be done
on all platforms.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Determine the need for double wide mode already in compute_config
stage as we need that information to figure out if horizontal
coordinates need to be adjusted.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simply inline the 100MHz default we're using. Having gunk around that
has leftover LVDS support on a platform that just doesn't have this
isn't of any use.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

First of all we should not be looking at fb->{width,height} as those do
not tell us what the actual pipe size is. Second of all we need to use
>= for the comparison.

So fix the comparison, and make use of the new pipe_src_{w,h} to
determine the real pipe source dimensions.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When the cursor x coordinate is exactly -cursor_width, the cursor is
invisible. And obviously the same holds for the y coordinate and
cursor_height.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather that mess about with hdisplay/vdisplay from requested_mode, add
explicit pipe src size information to pipe config.

Now requested_mode is only really relevant for dvo/sdvo output timings.
For everything else either adjusted_mode or pipe src size should be
used.

In many places where we end up using pipe source size, we should
actually use the primary plane size, but we don't currently store
that information explicitly. As long as we treat primaries as full
screen only, we can get away with this. Eventually when we move
primaries over to drm_plane, we need to fix it all up.

v2: Add a comment to explain what pipe_src_{w,h} are
    Add a note about primary planes to commit message
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move intel_crtc_active() to intel_display.c and make it available
elsewhere as well.

intel_edp_psr_match_conditions() already has one open coded copy,
so replace that one with a call to intel_crtc_active().

v2: Copy paste a big comment from danvet's mail explaining
    when we can ditch the extra checks
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

lpt_program_iclkip() wants to know the pixel clock. It should get that
information from adjusted_mode, not crtc->mode.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i9xx_set_pipeconf() attempts to get the current pixel clock from
requested_mode. requested_mode.clock may be totally bogus, so the
clock should come from adjusted_mode.

v2: Dropped the intel_compute_config() hunk due to killing of the
    INTEL_FDI_FREQ check
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Check and dump for port_clock.

v2: Also dump port_clock
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add a new pipe config check macro PIPE_CONF_CHECK_CLOCK_FUZZY() to make
it trivial and error proof to compare clocks in a fuzzy manner.

v2: Drop extra curly braces
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that adjusted_mode.clock no longer contains the pixel_multiplier, we
can kill the get_clock() callback and instead do the clock readout
in get_pipe_config().

Also i9xx_crtc_clock_get() can now extract the frequency of the PCH
DPLL, so use it to populate port_clock accurately for PCH encoders.
For DP in port A the encoder is still responsible for filling in
port_clock. The FDI adjusted_mode.clock extraction is kept in place
for some extra sanity checking, but we no longer need to pretend it's
also the port_clock.

In the encoder get_config() functions fill out adjusted_mode.clock
based on port_clock and other details such as the DP M/N values,
HDMI 12bpc and SDVO pixel_multiplier. For PCH encoders we will then
do an extra sanity check to make sure the dotclock we derived from
the FDI configuratiuon matches the one we derive from port_clock.

DVO doesn't exist on PCH platforms, so it doesn't need to anything
but assign adjusted_mode.clock=port_clock. And DDI is HSW only, so
none of the changes apply there.

v2: Use hdmi_reg color format to detect 12bpc HDMI case
v3: Set adjusted_mode.clock for LVDS too
v4: Rename ironlake_crtc_clock_get to ironlake_pch_clock_get,
    eliminate the useless link_freq variable.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add the 120MHz refernce clock case for PCH DPLLs.

Also determine the reference clock frequency more accurately by
checking for the PLLB_REF_INPUT_SPREADSPECTRUMIN refclk input
mode. The gen2 code already checked it, but it stil assumed a
fixed 66MHz refclk. Instead we need to consult the VBT for the
real value.

v2: Fix refclk for SSC panel case
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already extract the DPLL state to pipe_config, so let's make use of
it in i9xx_crtc_clock_get() and avoid the register reads.

This will also make the function closer to being useable with PCH DPLL
since the registers for those live in a different address.

Also kill the useless adjusted_mode.clock zeroing. It's already zero at
this point.

v2: Read out DPLL state in intel_crtc_mode_get()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Extract the code to calculate the dotclock from the link clock and M/N
values into a new function from ironlake_crtc_clock_get().

The new function can be used to calculate the dotclock for both FDI and
DP cases.

Also simplify the code a bit along the way.

v2: Don't forget about non-pch encoders in ironlake_crtc_clock_get()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The cursor is supposed to be disabled during crtc mode set (disabled by
ctrc disable). Assert this is the case.

v2: move cursor disabled assert next to plane asserts (Ville)
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to do fuzzy clock checks for other things besides
adjusted_mode.clock, so just pass two two clocks to compare
to intel_fuzzy_clock_check().
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>