drm/i915: Refactor ctg+ trickle feed disable

Pull the code to disable trickle feed for all primary planes into a
separate function.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable trickle feed in ironlake_init_clock_gating()

We disable trickle feed in all the (relevant) clock gating functions,
except ironlake_init_clock_gating(). Copy paste the same code there as
well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable trickle feed via MI_ARB_STATE for the gen4

According to BSpec, trickle feed should be disabled for BW and
mobile CL. Those constraints seem to match all of our gen4 chipsets.

Trickle feed is disabled via the MI_ARB_STATE register instead of
per plane controls on gen4.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable primary plane trickle feed for g4x

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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: enable 30bpp for DP outputs

We always limited the link bw calculations to 24bpp. Tested with
my shiny new high-bpc screen, seems to work as advertised.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65280
Tested-by: shui yangwei <yangweix.shui@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: pipe config quirk infrastructure plus sdvo mode.flags fix

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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

i915/drm: Add private api for power well usage

Haswell Display audio depends on power well in graphic side, it should
request power well before use it and release power well after use.
I915 will not shutdown power well if it detects audio is using.
This patch protects display audio crash for Intel Haswell C3 stepping board.

Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

ALSA: hda - Add power-welll support for haswell HDA

For Intel Haswell chip, HDA controller and codec have
power well dependency from GPU side. This patch added support
to request/release power well in audio driver. Power save
feature should be enabled to get runtime power saving.

There's deadlock when request_module(i915) in azx_probe.
It looks like:
device_lock(audio pci device) -> azx_probe -> module_request
(or symbol_request) -> modprobe (userspace) -> i915 init ->
drm_pci_init -> pci_register_driver -> bus_add_driver -> driver_attach ->
which in turn tries all locks on pci bus, and when it tries the one on the
audio device, it will deadlock.

This patch introduce a work to store remaining probe stuff, and let
request_module run in safe work context.

Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Reviewed-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

ALSA: hda - Move azx_first_init() into azx_probe_continue()

This is a preliminary work for the upcoming Haswell HDMI audio fixes.

azx_first_init() function can be safely called after the f/w loader,
since the f/w loader doesn't require the sound hardware initialization
beforehand.  Moving it into azx_probe_continue() cleans up the code
flow a bit.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

ALSA: hda - Fix runtime PM check

The device can support runtime PM no matter whether it support
signal wakeup or not. For some chips like Haswell which doesnot
support PME by default, this patch let haswell Display HD-A controller
enter runtime suspend, and bring more power saving whith power-well
feature enabled.

Signed-off-by: Wang Xingchao <xingchao.wang@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: update FBC maximum fb sizes

CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but
without proper front buffer invalidation on the last 2k lines, so
don't enable FBC on these cases for now.

v2: Use gen >= 5, not gen > 4 (Daniel).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: hw state readout support for pixel_multiplier

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Assert dpll running in intel_crtc_load_lut() on pre-PCH platforms

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Spruce up the commit message a lot.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Spruce up assert_sprites_disabled()

Make assert_sprites_disabled() operational on all platforms where
we currently have sprite support enabled.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Improve assert_planes_disabled()

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Disable/restore all sprite planes around modeset

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop overlay DPMS call from valleyview_crtc_enable

VLV doesn't have the old video overlay.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Follow the same sequence when disabling planes

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

v2: Mention IPS in the commit message

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable the overlay right after primary and cursor planes

Again follow the same sequence for all generations, because doing
otherwise just doesn't make sense.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always enable the cursor right after the primary plane

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: Egbert Eich <eich@suse.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Always load the display palette before enabling the pipe

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Revert "drm/i915: Include display_mmio_offset in sequencer index/data registers"

We use port I/O for VGA register access, so adding display_mmio_offset
is just wrong.

This reverts commit 56a12a509296c87d6f149be86c6694d312b21d35.

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

drm/i915: add ibx_irq_preinstall

So we can remove some duplicate code. All the PCHs are very similar
and right now the code is the same. I plan to add more code, so we
would have more duplicated code.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Track clients and print their object usage in debugfs

By stashing a pointer of who opened the device and keeping a list of
open fd, we can then walk each client and inspect how many objects they
have open. For example,

i915_gem_objects:
1102 objects, 613646336 bytes
663 [662] objects, 468783104 [468750336] bytes in gtt
  37 [37] active objects, 46874624 [46874624] bytes
  626 [625] inactive objects, 421908480 [421875712] bytes
282 unbound objects, 6512640 bytes
85 purgeable objects, 6787072 bytes
28 pinned mappable objects, 3686400 bytes
40 fault mappable objects, 27783168 bytes
2145386496 [536870912] gtt total

Xorg: 43 objects, 32243712 bytes (10223616 active, 16683008 inactive, 4096 unbound)
gnome-shell: 30 objects, 28381184 bytes (0 active, 28336128 inactive, 0 unbound)
xonotic-linux64: 1032 objects, 569933824 bytes (46874624 active, 383545344 inactive, 6508544 unbound)

v2: Use existing drm->filelist as pointed out by Ben.
v3: Not even stashing the task_struct is required as Ben pointed out
    drm_file->pid.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: set default value for config->pixel_multiplier

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: distinguish between error messages in DIDL initialization

Two exactly same error messages on different error paths makes debugging
difficult. Clarify the messages and distinguish them from each other.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: consolidate and tighten encoder cloning checks

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: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix DSPCLK_GATE_D for VLV

Fix the DSPCLK_GATE_D access for VLV. The code incorrectly tried to
poke at the ILK+ version of the register which is at the wrong offset.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: VLV doesn't have the ILK+ style LP watermark registers

The LP watermark registers don't exist on VLV, so don't touch them.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: check for strange pfit pipe assignemnt on ivb/hsw

Panel fitters on ivb/hsw are not created equal since not all of them
support the new high-quality upscaling mode. To offset this the hw
allows us to freely assign the pfits to pipes.

Since our code currently doesn't support this we might fall over when
taking over firmware state. So check for this case and WARN about it.
We can then improve the code once we've hit this in the wild. Or once
we decide to support the improved upscale modes, though that requires
global arbitrage of modeset resources across crtcs.

v2: Check for IS_GEN7 instead of IS_IVB || IS_HSW as suggested by
Paulo in his review comment.

Suggested-by: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Drop some no longer required mode/adjusted_mode parameters

We can get at this easily through intel_crtc->config now.

v2: Drop more stuff gcc spotted.

v3: Drop even more stuff gcc spotted.

v4: Yet more ...

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: store adjusted dotclock in adjusted_mode->clock

... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.

Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.

I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).

So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.

v2: Fix up ilk cpu pll handling.

v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.

v4: Rebase on top of Imre's is_cpu_edp removal.

v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
a new place which looked at the pixel_clock and so needed conversion.

v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
on top of the fdi dotclock handling fix in the fdi lanes/bw
computation code.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: refactor cpu eDP PLL handling a bit

This prepares a bit for the next big patch, where we switch the
semantics of the different clocks in the pipe config around.

Since I've broken cpu eDP PLL handling in the first version I've
figured some refactoring is in order.

Split out on request from Paulo Zanoni.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: clear up the fdi dotclock semantics for M/N computation

We currently mutliply the link_bw of the fdi link with the pixel
multiplier, which is wrong: The FDI link doesn't suddenly grow more
bandwidth. In reality the pixel mutliplication only happens in the PCH,
before the pixels are fed into the port.

But since we our code treats the uses the target clock after pixels
are doubled (tripled, ...) already, we need to correct this.

Semantically it's clearer to divide the target clock to get the fdi
dotclock instead of multiplying the bw, so do that instead.

Note that the target clock is already multiplied by the same factor,
so the division will never loose accuracy for the M/N computation.

The lane computation otoh used the wrong value, we also need to feed
the fdi dotclock to that.

Split out on a request from Paulo Zanoni.

v2: Also fix the lane computation, it used the target clock to compute
the bw requirements, not the fdi dotclock (i.e. adjusted with the
pixel multiplier). Since sdvo only uses the pixel multiplier for
low-res modes (with a dotclock below 100MHz) we wouldn't ever have
rejected a bogus mode, but just used an inefficient fdi config.

v3: Amend the commit message to explain better what the change for the
fdi lane config computation is all about. Requested by Paulo.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fold in IS_PNV checks from the split up find_dpll functions

Since I stand by my rule that splitting functions should only do an
exact copy, this is a follow-up patch.

Suggested-by: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: move find_pll callback to dev_priv->display

Now that the DP madness is cleared out, this is all only per-platform.
So move it out from the intel clock limits structure.

While at it drop the intel prefix on the static functions, call the
vtable entry find_dpll (since it's for the display pll) and rip out
the now unnecessary forward declarations.

Note that the parameters of ->find_dpll are still unchanged, but they
eventually need to be moved over to just take in a pipe configuration.
But currently a lot of things are still missing from the pipe
configuration (reflock, output-specific dpll limits and preferences,
downclocked dotclock). So this will happen in a later step.

Note that intel_g4x_limit has a peculiar case where it selects
intel_limits_i9xx_sdvo as the limit. This is pretty bogus and also not
used since the only output types left are DP and native TV-out which
both use special pre-tuned dpll values.

v2: Re-add comment for the find_pll callback (requested by Paulo) and
elaborate on why the transformation is correct for g4x platforms (to
clarify a review question from Paulo). Double up on that by adding a
WARN as suggested by Paulo Zanoni on irc.

v3: Initialize limits to NULL since gcc is now unhappy.

v4: v2/3 will blow up with a NULL dereference in ->find_dpll for dp and
TV-out ports, spotted by Paulo on irc. So just give up on this madness for
now, and leave this to be fixed in a later patch.

v5: Since the ever-so-slight change for g4x might result in some dpll
parameter computation failing spuriously where before it didn't for
ports with preset dpll settings (DP & TV-out) override this. For
paranoia also do it in the ilk+ code.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: split out intel_pnv_find_best_PLL

Pineview is just different.

Also split out i9xx_clock from intel_clock and drop the now redundant
struct device * parameter.

Note that in this patch I kill an XXX comment about 100MHz clocks. I
couldn't figure out what this is about, and we don't seem to have any
bug reports about this either. I suspect that it's a remnant from when
the i9xx and ilk+ modeset code was all in the same file since ilk+
does indeed have a 100MHz clock. So I've just killed it to stop the
cargo-culting.

Reviewed-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix EDID/sink-based bpp clamping

Since this is run in the compute config stage we need to check
the new_ pointers, i.e the stage output routing, not the current
modeset layout. Also there was a little logic bug in properly skipping
connectors: The old code did not skip any unused connectors and so
clamped to whatever was left in there (usually 0 if that connector
hasn't seen a EDID 1.4 screen ever since boot-up).

This has been broken when moving the pipe bpp selection in

commit 4e53c2e010e531b4a014692199e978482d471c7e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Mar 27 00:44:58 2013 +0100

    drm/i915: precompute pipe bpp before touching the hw

To avoid too much casting switch from drm_ to intel_ types.

Also add a bit of debug output to help reconstructing what's going
on.

v2: Try to clarify this a bit:
- s/pipe_config_set_bpp/compute_baseline_pipe_bpp/ to make it clearer
  at which stage this function is run. Also add a comment about what
  it does.
- Extract the sink clamping into it's own function.

v3: Actually make it compile.

v4: Split out all the prep refactoring to make the bugfix stick out
really badly. Also elaborate a bit in the commit message about the
nature of the bugfix.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: refactor sink bpp clamping

As a prep work to fix it up:
- Use intel_connector instead of drm_connector to avoid too much
  upcasting in the bugfix patch.
- Extract the connector bpp clamping from the loop-over-connectors
  logic.
- Bikeshed function names (to make it clearer that
  acompute_baseline_pipe_bpp runs in the compute stage of the modeset
  sequence) and add a comment to make it clearer what it does.

No functional change in this patch.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: optimize vblank waits in set_base_atomic

We only need to do them if the pipe is actually running and if the
framebuffers have changed. Removes two "wait for vblank timed out"
messages when doing a suspend/resume cycle on my i855gm.

v2: s/to_intel_ctrc(crtc)/intel_crtc/ spotted by Chris.

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: s/drm_i915_private_t/struct drm_i915_private/

People don't like typedefs these days. Eliminate their use from intel_fb.c.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Use container_of() in the fbdev code

Use container_of() instead of a cast to get struct intel_fbdev
from struct drm_fb_helper.

Also populate the fb_info->par correctly with the drm_fb_helper pointer
instead of the intel_fbdev pointer.

There's no actual functional change since the drm_fb_helper happens to
be the first member inside intel_fbdev.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove i915_hangcheck_hung

Rework of per ring hangcheck made this obsolete.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: detect hang using per ring hangcheck_score

Keep track of ring seqno progress and if there are no
progress detected, declare hang. Use actual head (acthd)
to distinguish between ring stuck and batchbuffer looping
situation. Stuck ring will be kicked to trigger progress.

This commit adds a hard limit for batchbuffer completion time.
If batchbuffer completion time is more than 4.5 seconds,
the gpu will be declared hung.

Review comment from Ben which nicely clarifies the semantic change:

"Maybe I'm just stating the functional changes of the patch, but in case
they were unintended here is what I see as potential issues:

1. "If ring B is waiting on ring A via semaphore, and ring A is making
   progress, albeit slowly - the hangcheck will fire. The check will
   determine that A is moving, however ring B will appear hung because
   the ACTHD doesn't move. I honestly can't say if that's actually a
   realistic problem to hit it probably implies the timeout value is too
   low.

2. "There's also another corner case on the kick. If the seqno = 2
   (though not stuck), and on the 3rd hangcheck, the ring is stuck, and
   we try to kick it... we don't actually try to find out if the kick
   helped"

v2: use atchd to detect stuck ring from loop (Ben Widawsky)

v3: Use acthd to check when ring needs kicking.
Declare hang on third time in order to give time for
kick_ring to take effect.

v4: Update commit msg

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Paste in Ben's review comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Rename the gtt_list to global_list

Since it will be used for the global bound/unbound list with full PPGTT,
this helps clarify things for upcoming code rework.

Recommended-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: unpin pages at unbind

If we properly keep track of the pages_pin_count, then when we later add
multiple address spaces, the put_pages doesn't need any special checks
to be able to perform it's job.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Rebased on top of the fix for stolen memory pinning.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Unpin stolen pages

The way the stolen handling works is we take a pin on the backing pages,
but we never actually get a reference to the bo. On freeing objects
allocated with stolen memory, the final unref will end up freeing the
object with pinned pages count left. To enable an assertion to catch
bugs in this code path, this patch cleans up that remaining pin.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Make stolen use pin pages

This makes it easier to catch leaks.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Demote unknown param to DRM_DEBUG

It's not terribly interesting to know that a parameter doesn't exist,
and it can get in the way of interesting messages, especially with the
staggered VECS merging as we've done.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add i915_ips_status debugfs entry

It just prints whether it's supported/enabled/disabled. Feature
requested by the power management team.

v2: Checkpatch started complaining about seq_printf with 1 argument.

Requested-by: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add enable_ips module option

IPS is still enabled by default. Feature requested by the power
management team.

This should also help testing the feature on some early pre-production
hardware where there were relationship problems between IPS and PSR.

v2: Rebase on top of the newest IPS implementation.
v3: Check i915_enable_ips at compute_config, not supports_ips, so the
    kernel parameter will be ignored at haswell_get_pipe_config.

Requested-by: Kristen Accardi <kristen.c.accardi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: implement IPS feature

Intermediate Pixel Storage is a feature that should reduce the number
of times the display engine wakes up memory to read pixels, so it
should allow deeper PC states. IPS can only be enabled on ULT pipe A
with 8:8:8 pipe pixel formats.

With eDP 1920x1080 and correct watermarks but without FBC this moves
my PC7 residency from 2.5% to around 38%.

v2: - It's tied to pipe A, not port A
    - Add pipe_config support (Chris)
    - Add some assertions (Chris)
    - Rebase against latest dinq
v3: - Don't ever set ips_enabled to false (Daniel)
    - Only check for ips_enabled at hsw_disable_ips (Daniel)
v4: - Add hsw_compute_ips_config (Daniel)
    - Use the new dump_pipe_config (Daniel)

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix up the edp power well check

Now that we track the cpu transcoder we need accurately in the pipe
config we can finally fix up the transcoder check. With the current
code eDP on port D will be broken since we'd errornously cut the
power.

For reference see

commit 2124b72e6283c4e84a55e71077fee91793f4c801
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Mar 22 14:07:23 2013 -0300

    drm/i915: don't disable the power well yet

v2:
- Kill the now outdated comment (Paulo)
- Add the missing crtc->base.enabled check and consolidate it (Paulo)
- Smash all checks together, looks neater that way.

v3: Kill the unused encoder variable.

Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam

This will let userland only try to use the new ring
when the appropriate kernel is present

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()

A user can run batchbuffer via VEBOX ring.

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add VEBOX into debugfs

v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)

v3: s/hsw/hws in debugfs which I introduced in v2 (Jon)

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
[Order changed, and modified by]
CC: "Bloomfield, Jon" <jon.bloomfield@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Enable vebox interrupts

Similar to a patch originally written by:

v2: Reversed the meanings of masked and enabled (Haihao)
Made non-destructive writes in case enable/disabler rps runs first
(Haihao)

v3: Reword error message (Damien)
Modify postinstall to do the right thing based on previous fixup. (Ben)

CC: Xiang, Haihao <haihao.xiang@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: vebox interrupt get/put

v2: Use the correct lock to protect PM interrupt regs, this was
accidentally lost from earlier (Haihao)
Fix return types (Ben)

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: consolidate interrupt naming scheme

The motivation here is we're going to add some new interrupt definitions
and handling outside of the GT interrupts which is all we've managed so
far (with some RPS exceptions). By consolidating the names in the future
we can make thing a bit cleaner as we don't need to define register
names twice, and we can leverage pretty decent overlap in HW registers
since ILK.

To explain briefly what is in the comments: there are two sets of
interrupt masking/enabling registers. At least so far, the definitions
of the two sets overlap. The old code setup distinct names for
interrupts in each set, ie. one for global, and one for ring. This made
things confusing when using the wrong defines in the wrong places.

rebase: Modified VLV bits

v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien)

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Convert irq_refounct to struct

It's overkill on older gens, but it's useful for newer gens.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: make PM interrupt writes non-destructive

PM interrupts have an expanded role on HSW. It helps route the EBOX
interrupts. This patch is necessary to make the existing code which
touches the mask, and enable registers more friendly to other code paths
that also will need these registers.

To be more explicit:
At preinstall all interrupts are masked and disabled. This implies that
preinstall should always happen before any enabling/disabling of RPS or
other interrupts.

The PMIMR is touched by the workqueue, so enable/disable touch IER and
IIR. Similarly, the code currently expects IMR has no use outside of the
RPS related interrupts so they unconditionally set 0, or ~0. We could
use IER in the workqueue, and IMR elsewhere, but since the workqueue
use-case is more transient the existing usage makes sense.

Disable RPS events:
IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts

Enable RPS events:
IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events
(really shouldn't happen)

v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in
enable/disable rps functions (Haihao)

v3: Bug found by Chris where we were clearing the wrong bits at rps
disable.
    expanded commit message

v4: v3 was based off the wrong branch

v5: Added the setting of PMIMR because of previous patch update

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add PM regs to pre/post install

At the moment, these values are wiped out anyway by the rps
enable/disable. That will be changed in the next patch though.

v2: Add post install setup to address issue found by Damien in the next
patch.
replaced
WARN_ON(dev_priv->rps.pm_iir != 0);
with rps.pm_iir = 0;

With the v2 of this patch and the deferred pm enabling (which changed
since the original patches) we're now able to get PM interrupts before
we've brought up enabled rps. At this point in boot, we don't want to do
anything about it, so we simply ignore it. Since writing the original
assertion, the code has changed quite a bit, and I believe removing this
assertion is perfectly safe.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: I don't agree with the justification to drop the WARN and
added a FIXME to that effect.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Create an ivybridge_irq_preinstall

Just duplicates ironlake_irq_preinstall for now.

v2: Add new PCH_NOP check (Damien)
Add SDEIMR comment (Damien)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Update now outdated comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Create a more generic pm handler for hsw+

HSW has some special requirements for the VEBOX. Splitting out the
interrupt handler will make the code a bit nicer and less error prone
when we begin to handle those.

The slight functional change in this patch (queueing work while holding
the spinlock) is intentional as it makes a subsequent patch a bit nicer.
The change should also only effect HSW platforms.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add support for 5/6 data buffer partitioning on Haswell

Now we compute the results for both 1/2 and 5/6 partitioning and then
use hsw_find_best_result to choose which one to use.

With this patch, Haswell watermarks support should be in good shape.
The only improvement we're missing is the case where the primary plane
is disabled: we always assume it's enabled, so we take it into
consideration when calculating the watermarks.

v2: - Check the latency when finding the best result

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: properly set HSW WM_LP watermarks

We were previously only setting the WM_PIPE registers, now we are
setting the LP watermark registers. This should allow deeper PC
states, resulting in power savings.

We're only using 1/2 data buffer partitioning for now.

v2: Merge both hsw_compute_pri_wm_* functions (Ville)
v3: - Simplify hsw_compute_wm_results (Ville)
    - Rebase due to changes on the previous patch
v4: Unconfuse wm_lp/level (Ville)

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: properly set HSW WM_PIPE registers

We were previously calling sandybridge_update_wm on HSW, but the SNB
function didn't really match the HSW specification, so we were just
writing the wrong values.

With this patch, the haswell_update_wm function will set the correct
values for the WM_PIPE registers, but it will still keep all the LP
watermarks disabled.

The patch may look a little bit over-complicated for now, but it's
because much of the infrastructure for setting the LP watermarks is
already in place, so we won't have too much code churn on the patch
that sets the LP watermarks.

v2: - Fix pixel_rate on panel fitter case (Ville)
    - Try to not overflow (Ville)
    - Remove useless variable (Ville)
    - Fix p->pri_horiz_pixels (Paulo)
v3: - Fix rounding errors on hsw_wm_method2 (Ville)
v4: - Fix memcmp bug (Paulo)

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix pch_nop support

This was accidentally broken in the south error interrupt handling
work:

commit 8664281b64c457705db72fc60143d03827e75ca9
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Apr 12 17:57:57 2013 -0300

    drm/i915: report Gen5+ CPU and PCH FIFO underruns

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Vebox ringbuffer init

v2: Add set_seqno which didn't exist before rebase (Haihao)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add HAS_VEBOX

The flag will be useful to help share code between IVB, and HSW as the
programming is similar in many places with this as one of the major
differences.

Signed-off-by: Xiang, Haihao <haihao.xiang@intel.com>
[Commit message + small fix by]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Rename ring flush functions

Historically we considered the render ring to have special flush
semantics and everything else to fall under a more general umbrella.
Probably by coincidence more than anything we decided to make the bsd
ring have the default *other* flush. As the new vebox ring exposes, the
bsd ring is actually the weird one. Doing this allows us to call
gen6_ring_flush for the vebox because calling blt_ring_flush would be
weird...

This patch should have no functional change.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Add VECS semaphore bits

Like the other rings, the VECS supports semaphores. The semaphore stuff
is a bit wonky so this patch on it's own should be nice for review.

This patch should have no functional impact.

v2: Fix the English parts of clarification (again, register names were
right, text was reversed) (Damien)
Restore the still valid invariant. (Damien)
The bsd semaphore register should be MI_SEMAPHORE_SYNC_VVE (Damien)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Introduce VECS: the 4th ring

The video enhancement command streamer is a new ring on HSW which does
what it sounds like it does. This patch provides the most minimal
inception of the ring.

In order to support a new ring, we need to bump the number. The patch
may look trivial to the untrained eye, but bumping the number of rings
is a bit scary. As such the patch is not terribly useful by itself, but
a pretty nice place to find issues during a bisection.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Semaphore MBOX update generalization

This replaces the existing MBOX update code with a more generalized
calculation for emitting mbox updates. We also create a sentinel for
doing the updates so we can more abstractly deal with the rings.

When doing MBOX updates the code must be aware of the /other/ rings.
Until now the platforms which supported semaphores had a fixed number of
rings and so it made sense for the code to be very specialized
(hardcoded).

The patch does contain a functional change, but should have no
behavioral changes.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Comments for semaphore clarification

Semaphores are tied very closely to the rings in the GPU. Trivial patch
adds comments to the existing code so that when we add new rings we can
include comments there as well. It also helps distinguish the ring to
semaphore mailbox interactions by using the ringname in the semaphore
data structures.

This patch should have no functional impact.

v2: The English parts (as opposed to register names) of the comments
were reversed. (Damien)

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: release cursor when crtc is destroyed

crtc is holding a reference to a cursor bo and it needs
to be released when crtc is destroyed so that we don't leak
the cursor bo.

v2: Enhance set and move cursor so that disabled
cursor is handled correctly (Ville Syrjälä)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Avoid promoting a simulated hang to 'wedged'

It appears that a beneficial side-effect of Mika's more accurate hangman
work is to speed up hang detection and execution. This exposes a bug in
the reset code that then treats repeated simulated hangs as an
indication that the machine is wedged. Jiggle the code around so that we
only do the simulation processing from the hangcheck and avoid confusing
it with a real hang.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65060
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: drop a few really redundant WARNs in hsw mode_set

- Correct cpu->pch display matching is already check when we detect
  the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
  disabling and in c) the modeset state checker. No need to go
  overboard and also check it in in between a) and b).

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add basic pipe config dump support

All this pipe config abstraction adds another layer of complexity, so
it's good to have better visibility into what's going on exactly.
Doesn't dump out everything yet, and some bits are a bit duplicated
but this should be a good start.

Note that at boot-up a lot of the fields are 0 even for enabled pipes,
this is simply because our hw state readout code doesn't support
everything.

v2: Remove a few more now redudant debug output lines.

v3: Review from Paulo
- use transcoder_name
- fix up format specifiers
- add missing ':' in debug output

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fix error return code in init_pipe_control()

Fix to return -ENOMEM in the kmap() error handling case
instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: document why dvo/sdvo/crt need a special dpms function

In the cloned case, changing just one output but keeping the other, the
pipe state won't change and intel_crtc_update_dpms will be a nop, but we
still need to update the dpms state of the output being changed.

Only dvo, sdvo and crt are cloneable, so only those three have special
dpms functions.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: hw state readout&check support for cpu_transcoder

This allows us to drop a bunch of ugly hacks and finally implement
what

commit cc464b2a17c59adedbdc02cc54341d630354edc3
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Jan 25 16:59:16 2013 -0200

    drm/i915: set TRANSCODER_EDP even earlier

tried to achieve, but that was reverted again in

commit bba2181c49f1dddf8b592804a1b53cc1a3cf408a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Mar 22 10:53:40 2013 +0100

    Revert "drm/i915: set TRANSCODER_EDP even earlier"

Now we should always have a consistent cpu_transcoder in the
pipe_config.

v2: Fix up the code as spotted by Paulo:
- read the register for real
- assign the right pipes
- break out if the hw state doesn't make sense

v3: Shut up gcc.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: fixup i915_pipe_enabled check in i915_irq.c

Well, as well as we can without completely revamping the drm vblank
code. The issue are that
- The vblank code needs to work on both ums and kms.
- It deals always deals with pipes.
- It doesn't take any of the kms locks.

The last part is not really fixable without revamping the drm vblank
code, since the drm core <-> driver interactions is a veritable pile
of spaghettis. But the other pieces can be fixed by switching on the
MODESET driver flag and either checking the hw state directly (ums
case) or just querying our sw tracking (with broken locking, but
that's not worse than what we've had).

Note that this essentially reverts

commit 702e7a56af3780d8b3a717f698209bef44187bb0
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Oct 23 18:29:59 2012 -0200

    drm/i915: convert PIPECONF to use transcoder instead of pipe

for the ums case, which will fix a NULL deref (since we really don't
have any crtcs set up).

But the real reason to do this is to drop our reliance on the
cpu_transcoder: By only checking intel_crtc->active we don't need to
make sure that the pipe_config (or at least the cpu_transcoder)
contain safe values even when the pipe is off.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: remove unused is_cpu_edp()

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: replace is_cpu_edp() with a check for port A

The patch changes all remaining is_cpu_edp() check with a check for port
A. We can do this, since in all these cases ValleyView is handled
separately and port A is always a CPU side eDP port.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: merge VLV eDP and DP AUX clock divider calculation

On ValleyView for both eDP and DP the AUX input clock is 200MHz, so we
can calculate for both the clock divider for the 2MHz target rate at the
same place. Afterwards we can also replace the is_cpu_edp() check with a
check for port A.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: stop using is_cpu_edp() in intel_disable/post_disable_dp

Based on 3739850b46f - "drm/i915: disable the cpu edp port after the
cpu pipe" and the bspec disabling sequence for IVB and older it seems we
have to distinguish only the CPU vs. PCH port case, whether it's a DP or
eDP doesn't seem to matter. For IVB and older on the CPU side we can
only have eDP on port A, DP ports can only be on the PCH side. On VLV we
have only CPU side eDP/DP ports, no PCH. So the condition for the
disabling sequence we need for CPU ports is port == A || IS_VLV.

This allows us to remove is_cpu_edp() completely in a later patch.

v2:
- simplify (and fix) the condition for CPU side ports and adjust the
  commit message accordingly (Daniel)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: release scratch page at module unload

Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Call context fini at cleanup

If contexts were actually initialized, and we fail somewhere later during
init this would possibly leak memory, and lead to some error messages
about unclean takedown. As the odds of this occurring, and someone
actually caring/noticing are pretty slim, the patch isn't terribly
important.

Found by code inspection while working on something else.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: context debug messages

Add some debug messages to help figure out what goes wrong on context
initialization.

Later in the PPGTT series, I ended up having a lot of failures after
reset. In many cases it was extra difficult to debug because I hadn't
even realized that contexts failed to reinitialize after reset (again an
artifact of some later patches).

This fairly benign patch does help debug some potential issues which
arise later.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use drm_mm_takedown

I noticed this while doing the VMA abstraction. AFAICT, it won't
actually fix anything, but it is the correct thing to do.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: use mappable size for fb kickout

The GTT start is either 0 in the KMS case, or some value which is set
only after the init IOCTL in the UMS case. In both cases, we don't have
this information until after we've tried to kick out the firmware fb.

This patch should have no functional change since we kzalloc the GTT
struct anyway. It only clarifies the situation for people who end up
having to look at that code.

This weirdness was introduced in:

commit 93d187993b783c68383a884091a600d9ad499ea6
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jan 17 12:45:17 2013 -0800

    drm/i915: Remove use of gtt_mappable_entries

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: pre-fixes for checkpatch

Since I'll need to modify i915_gem_object_bind_to_gtt(), fix the errors
now to get checkpatch to not complain.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict with Chris' improved debug output, and
bikeshed the new variable with s/max/gtt_max/ a bit while at it.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix error state memory leaks

Found with kmemleak.

Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: introduce i915_hangcheck_ring_hung

In preparation to track per ring progress in hangcheck,
add i915_hangcheck_ring_hung.

v2: omit dev parameter (Ben Widawsky)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: track ring progression using seqnos

Instead of relying in acthd, track ring seqno progression
to detect if ring has hung.

v2: put hangcheck stuff inside struct (Chris Wilson)

v3: initialize hangcheck.seqno (Ben Widawsky)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: pass seqno to i915_hangcheck_ring_idle

In preparation for next commit, pass seqno as a parameter
to i915_hangcheck_ring_idle as it will be used inside
i915_hangcheck_elapsed.

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add haswell_update_sprite_wm

On Haswell, whenever we change the sprites we need to completely
recalculate all the watermarks, because the sprites are one of the
parameters to the LP watermarks, so a change on the sprites may
trigger a change on which LP levels are enabled.

So on this commit we store all the parameters we need to store for
proper recalculation of the Haswell WMs and then call
haswell_update_wm.

Notice that for now our haswell_update_wm function is not really using
these parameters we're storing, but on the next commits we'll use
these parameters.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: add "enable" argument to intel_update_sprite_watermarks

Because we want to call it from the "sprite disable" paths, since on
Haswell we need to update the sprite watermarks when we disable
sprites.

For now, all this patch does is to add the "enable" argument and call
intel_update_sprite_watermarks from inside ivb_disable_plane. This
shouldn't change how the code behaves because on
sandybridge_update_sprite_wm we just ignore the "!enable" case. The
patches that implement Haswell watermarks will make use of the changes
introduced by this patch.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: change VLV IOSF sideband accessors to not return error code

We never check the return values, and there's not much we could do on
errors anyway. Just simplify the signatures. No functional changes.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>