Nowadays (i.e. with Valleyview) we also have edp on non-PCH_SPLIT
platforms, so just checking for LVDS is not good enough.

Secondly we have full pfit pipe config tracking, so we'll correctly
disable the pfit as part of the initial modeset.

For fastboot we need a bit of work here to correctly kill unsupported
configs (if e.g. the pfit is used on anything else than the built-in
panel). But since that's not yet supported we don't need to worry.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again we don't really support different settings, so don't let the
BIOS sneak stuff through.

Since the motivation for this patch series is to ensure we have the
correct gamma table mode selected also add the required write to the
GAMMA_MODE register to select the 8bit legacy table.

And since I find lowercase letters in #defines offensive, also
bikeshed those.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Same reasons as for the previous patch, just no bug report about
anything going wrong yet: We only support exactly the mode we program,
so don't leave any stale BIOS state behind.

Again this will be fun to properly track for fastboot.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Dragging random garbage along from the BIOS isn't a good idea, since
we really only support exactly what we've set up.

In the specific case for the bug reporter the BIOS used the 10bit
gamma table, but since we only support an 8bit table the dark colors
ended up all wrong and the light ones all unadjusted.

Note that this has a nice implication for fastboot, it essentially
means that we have quite a bit more state to check and compare before
we can decide whether fastboot is possible.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65593Reported-and-Tested-by: NThomas Hebb <tommyhebb@gmail.com>
Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a nice comment saying that the pixel multiplier only sticks
once the vco is on and stable. The only problem is that the enable bit
wasn't set at all. This patch fixes this and so brings the ilk+ pch
pll code in line with the i8xx/i9xx pll code. Or at least improves
matters a lot.

This should fix sdvo on ilk-ivb for low-res modes.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just the plumbing, all the modeset and enable code has not yet been
switched over to use the new state. It seems to be decently broken
anyway, at least wrt to handling of the special pixel mutliplier
enabling sequence. Follow-up patches will clean up that mess.

Another missing piece is more careful handling (and fixup) of the fp1
alternate divisor state. The BIOS most likely doesn't bother to
program that one to what we expect. So we need to be more careful with
comparing that state, both for cross checking but also when checking
for dpll sharing when acquiring shared dpll. Otherwise fastboot will
deny a few shared dpll configurations which would otherwise work.

v2: We need to memcpy the pipe config dpll hw state into the pll, for
otherwise the cross-check code will get angry.

v3: Don't forget to read the pch pll state in the crtc get_pipe_config
function for ibx/ilk platforms.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we have proper hw state reconstruction we should never have a
case where we don't have the software dpll state properly set up. So
add WARNs to the respective !pll cases in enable/disabel_shared_dpll.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simply grew too large and needed to be split up into parts.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simply grew too big. This also makes the fixup and restore logic in
setup_hw_state stand out a bit more clearly.
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently still with an empty register state, this will follow in a
next step. This one here just creates the new vfunc and uses it for
cross-checking, initial state takeover and the dpll assert function.

And add a FIXME for the ddi pll readout code, which still needs to be
converted over.

v2:
- Add some hw state readout debug output.
- Also cross check the enabled crtc counting.

Note that I've botched up the patch ordering, and before this patch
we've read out the pll selection correctly, but did not reconstruct
the refcounts properly. See the bug link.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65673Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So don't try to store it in the DPLL_FP register.

Otherwise it looks like the limits for pineview are correct: It has
it's own clock computation code, which doesn't use an offset for n
divisors, and the register value based m limits look sane enough.

v2: Rebase on top of the pineview clock refactor and fixup up the
commit message: It's m1 pnv doens't care about, not m2!

Quoting Damien's review:

  - "n can vary between 2 and 6, but we declare the 3-6 as limits.
  - "p1 seems to be able to go up to 9
  - "the m upper limit seems a bit big, but the docs are a bit shy on
    that values for pnv.

"Otherwise, the change itself seems good:"
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The hw state readout code for the pipe config will now check
this for us, so rip out this hand-rolled complexity.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Looks at first like a bit of overkill, but
- Haswell actually wants different enable/disable functions for
  different plls.
- And once we have full dpll hw state tracking we can move the full
  register setup into the ->enable hook.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Using ids in register macros is much more common in our driver. Also
this way we can reduce the platform specific stuff a bit.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An id to match the idx (useful for register access macros) and a name
fore neater debug output.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the future this won't be just for pch plls, so move it into the
shared dpll init code.

v2: Bikeshed the uncessary {} away while applying to appease
checkpatch.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Well, the first step of a long road at least, it only reads out
the pipe -> shared dpll association thus far. Other state which needs
to follow:

- hw state of the dpll (on/off + dpll registers). Currently we just
  read that out from the hw state, but that doesn't work too well when
  the dpll is in use, but not yet fully enabled. We get away since
  most likely it already has been enabled and so the correct state is
  left behind in the registers. But that doesn't hold for atomic
  modesets when we want to enable all pipes at once.

- Refcount reconstruction for each dpll.

- Cross-checking of all the above. For that we need to keep the dpll
  register state both in the pipe and in the shared_dpll struct, so
  that we can check that every pipe is still connected to a correctly
  configured dpll.

Note that since the refcount resconstruction isn't done yet this will
spill a few WARNs at boot-up while trying to disable pch plls which
have bogus refcounts. But since there's still a pile of refactoring to
do I'd like to lock down the state handling as soon as possible hence
decided against reordering the patches to quiet these WARNs - after
all the issues they're complaining about have existed since forever,
as Jesse can testify by having pch pll states blow up consistently in
his fastboot patches ...

v2: We need to preserve the old shared_dpll since currently the
shared dpll refcount dropping/getting is done in ->mode_set. With
the usual pipe_config infrastructure the old dpll id is already lost
at that point, hence preserve it in the new config.

v3: Rebase on top of the ips patch from Paulo.

v4: We need to unconditionally take over the shared_dpll id from the
old pipe config when e.g. doing a direct pch port -> cpu edp
transition.

v5: Move the saving of the old shared_dpll id to an ealier patch.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The bits are evenly space, so we can cut down on two big switch
blocks. This also greatly simplifies the hw state readout which
follows in the next patch.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the big sed-job prep work done this is now really simple. With
the exception that we only assign the right shared dpll id in the
->mode_set callback but also depend upon the old one still being
around.

Until that mess is fixed up we need to jump through a few hoops to
keep the old value save.

v2: Kill the funny whitespace spotted by Chris.

v3: Move the shared_dpll pipe config fixup into this patch as noticed
by Ville. Also unconditionally set the shared_dpll with the current
one, since otherwise we won't handle direct pch port -> cpu edp
transitions correctly.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Dealing with discrete enum values is simpler for hw state readout and
pipe config computations than pointers - having neat names instead of
chasing pointers should look better in the code.

This isn't a that good reason for pch plls, but on haswell we actually
have 3 different types of plls: WRPLL, SPLL and the DP clocks. Having
explicit names should help there.

Since this also adds the intel_crtc_to_shared_dpll helper to further
abstract away the crtc -> dpll relationship this will also help to
make the next patch simpler, which moves the shared dpll into the pipe
configuration.

Also note that for uniformity we have two special dpll ids: NONE for
pipes which need a shared pll but don't have one (yet) and private for
when there's a non-shared pll (e.g. per-pipe or per-port pll).

I've thought whether we should also add a 2nd enum for the type of the
pll we want (for really generic pll selection code) but thrown that
idea out again - likely there's too much platform craziness going on
to be able to share the pll selection logic much.

Since this touched all the shared_pll functions a bit I've also done
an s/intel_crtc/crtc/ replacement on a few of them.

v2: Kill DPLL_ID_NONE. It's probably better to call it DPLL_ID_INVALID and use
it to check that the compute config stage assigns a dpll to every pipe.
But since that code isn't ready yet until we move the dpll selection out
of the ->mode_set callback, there's no use for it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For fastboot we need some support to read out the sharing state of
plls, at least for platforms where they can be shared (or freely
assigned at least). Now for ivb we already have pretty extensive
infrastructure for tracking pch plls, and it took us an aweful lot of
tries to get that remotely right. Note that hsw could also share plls,
but even now they're already freely assignable. So we need this on
more than just ivb.

So on top of the usual fastboot fun pll sharing seems to be an
additional step up in fragility. Hence a common infrastructure for all
shared/freely assignable display plls seems to be in order.

The plan is to have a bit of dpll hw state readout code, which can be
used individually, but also to fill in the pipe config. The hw state
cross check code will then use that information to make sure that
after every modeset every pipe still is connected to a pll which still
has the correct configuration - a lot of the pch pll sharing bugs
where due to incorrect sharing.

We start this endeavour with a simple s/pch_pll/shared_dpll/ rename
job.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Before I start to make a complete mess out of this, crank up
the paranoia level a bit.

v2: Kill the has_pch_encoder check in put_shared_dpll - it's invalid
as spotted by Ville since we currently only put the dpll when we
already have the new pipe config. So a direct pch port -> cpu edp
transition will hit this.

v3: Now that I've lifted my blinders add the WARN_ON Ville requested.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Simlar to how disable already works on haswell. This is possible
since we now carefully track the pch state in the pipe config.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We ->mode_set is called we can't just blindly reuse an existing pll
since that might be shared with a different, still active pch output.

v2: Only update the pll settings when the pch pll is know to be
unused, otherwise we can wreak havoc with a running pipe. Which in the
case of DP will likely result in a black screen due to loss of link
lock.

v3: Tighten up the asserts a bit more, especially make sure that the
pch pll is still enabled when we try to disable it. This would have
caught the bug fixed in this patch.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Don't enable the cursor until g4x_fixup_plane() had a chance to do
cast its magic spell.

Egbert writes:
"Today I had the chance to test this. First I tried
 if I can still reproduce the blank with this patch
 added when I disable my voodoo g4x_fixup_plane():
 It turned out it still happens however very rarely
 (like 1 out of 20 tries). When I reenabled my voodoo
 the issue still occurred.
 I had to switch two lines around, ie:

         intel_enable_plane(dev_priv, plane, pipe);
         if (IS_G4X(dev))
                 g4x_fixup_plane(dev_priv, pipe);
 +       intel_crtc_update_cursor(crtc, true);

 to avoid the blank screen issue - which is it didn't
 happen in ~75 tries."

v2: Add a comment to remind people of the ordering constraints
Acked-by: NEgbert Eich <eich@suse.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is required for tracking render damage for use with FBC and will be
used in subsequent patches.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The docs say that the trickle feed disable bit is present (for primary
planes only, not video sprites) on CTG, and that it must be set
for ELK. Just set it for all g4x chipsets.

v2: Do it in init_clock_gating too
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>

For various reasons the hw state readout might not be able to
faithfully match the hw state:
- broken hw (like the case which motivated this patch here where the
  sdvo encoder does not implemented mandatory functionality
  correctly).
- platforms which are not supported fully with the pipe config
  infrastructure
- if our code doesn't support a given hw configuration natively, e.g.
  special restrictions on the per-pipe panel fitters when they're used
  in high-quality scaling modes.

In all these cases both fastboot and the hw state cross checker need
to be aware of these cases and act accordingly. To be able to do this
add a new quirk flag to the pipe config structure.

The specific case at hand is an sdvo encoder which doesn't implement
the get_timings function, so adjusted_mode flags will be wrong. The
strange thing though is that the encoder _does_ work, even though it
doesn't implement any of the timings functions (so neither get nor
set, neither for input nor output timings).

Not that non-compliant sdvo encoder are any surprise at all ...

v2:
- Don't read random garbage from the dtd if the get_timings call
  failed (suggested by Chris).
- Still check the interlaced flag, that's read out from someplace
  else. We want maximal paranoia, after all.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Incomplete since ilk+ support needs proper pch dpll tracking first.
SDVO get_config parts based on a patch from Jesse Barnes, but fixed up
to actually work.

v2: Make sure that we call encoder->get_config _after_ we
get_pipe_config to be consistent in both setup_hw_state and the
modeset state checker. Otherwise the clever trick with handling the
pixel mutliplier on i915G/GM where the encoder overrides the default
value of 1 from the crtc get_pipe_config function doesn't work.
Spotted by Imre Deak.

v3: Actually cross-check the pixel mutliplier (but not on pch split
platforms for now). Now actually also tested on a i915G with a sdvo
encoder plugged in.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Adding more context from Ville's reply to Rodrigo's question why we
need this:

"The spec says that on some hardware you need to PLL running before you
can poke at the palette registers. I didn't actually try to anger the
hardware so I'm not really sure what would happen otherwise, but IIRC
Jesse said something about a hard system hang..."

And generally documenting such ordering constraints with asserts is
Just Good.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Spruce up the commit message a lot.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make assert_sprites_disabled() operational on all platforms where
we currently have sprite support enabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Ever since gen4 primary planes were fixed to pipes.

And for gen2-3, don't check plane B if it doesn't exist.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Disable/restore sprite planes around mode-set just like we do for the
primary and cursor planes. Now that we have working sprite clipping,
this actually works quite decently.

Previosuly we didn't even bother to disable sprites when changing mode,
which could lead to a corrupted sprite appearing on the screen after a
modeset (at least on my IVB). Not sure if all hardware generations would
be so forgiving when enabled sprites end up outside the pipe dimensons.

v2: Disable rather than enable sprites in ironlake_crtc_disable()
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV doesn't have the old video overlay.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

First disable FBC, then IPS, then disable all planes, and finally
disable the pipe.

v2: Mention IPS in the commit message
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again follow the same sequence for all generations, because doing
otherwise just doesn't make sense.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Follow the same sequence when enabling the cursor plane during
modeset. No point in doing this stuff in different order on different
generations.

This should also avoid a needless wait for vblank for the g4x cursor
workaround when the cursor gets enabled anyway.
Acked-by: NEgbert Eich <eich@suse.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Loading the palette after the planes are enabled can risk showing
incorrect colors. ILK+ already load the palette before even the pipe
is enabled. Just follow the same order for gen2-4 and VLV.

According to BSpec the requirements for palette access are
display core clock and display PLL running. In certain platforms
just the core clock may be enough. But we definitely should have both
running when this gets called during the modeset.

v2: Amend the commit message with some display PLL/core clock info
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This way we can simplify the code quite a bit.

Also add a WARN in the sdvo code to complain about a bogus value
and kill the readout code in intel_ddi.c that Jesse sneaked in.
HW state readout for the pixel multiplier will work a bit differently
in the end.

v2: Rebase on top of the fdi pixel mutliplier handling fix.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only lvds/tv did actually check for cloning or not, but many more
places should.

Notices because my ivb tried to enable both cpu edp and vga on the
first crtc - the resulting confusion between has_pch_encoder,
has_dp_encoder but not actually being a pch dp encoder resulting in
hilarity (hitting a BUG).

We _really_ need an igt to random-walk our modeset space more
exhaustively.

The bug seems to have been exposed due to a race in the hw load
detection support for VGA: Right after a hotplug VGA was still
detected as connected, but obviously reading the EDID wasn't possible
any more. Hence why restarting X a bit later fixed things. Due to the
1024x756 fallback resolution suddenly more outputs had the same
resolution.

On top of that SNA was confused with the possible_clones mask, trying
to clone outputs which cannot be cloned. That bug is now fixed with

commit fc1e0702b25e647cb423851fb7228989fec28bd6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed May 29 11:25:28 2013 +0100

    sna: fixup up possible_clones kms->X impedance mismatch

v2: Kill intel_encoder_check_is_cloned, spotted by Paulo.

v3: Drop the now unused pipe param.

v4: Kill the stray printk Chris spotted.

v5: Elaborate on how the bug in userspace happened and why it was racy
to reproduce.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>