Even though "we have enough padding that it should be ok", round up the
watermark entries to the next unit to be on the safe side...

v2: Use the DIV_ROUND_UP macro
v3: Spotted a few more missing round-ups.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

When trying to set other display mode besides the fixed panel mode, the
panel fitting should be enabled. This is similar to LVDS.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This makes them sort to the front in X, which makes them likely to be
the primary outputs if you haven't specified a preference in your DE,
which is likely to be what you want.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The original i965, including the revised G35 and Q35, requires an
alignment of 128K for the display surface with linear memory, so
increase the requirement from 64k for these chipsets. For the later
chipsets in the i965 family, only a 4k alignment is required. (So
long as we do not start performing asynchronous flips.)

Note the impact of this should be slight as on i965 we should be using a
tiled frontbuffer for anything up to a 4096x4096 display.

v2: compilation fixes and note that the docs do not exclude the G35 from
the extra alignment.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Unmask the bits for link training reporting before starting link
training.  If stage 1 training finished before we unmask them, then we'd
spin around in a loop a few times until smashing on through.  Which is
harmless, since training _did_ succeed, it just looks ugly in dmesg.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Since mode->clock is in kHz we should be checking against 2700000
instead of just 27000.  This patch gets my x201s working again (well
working as well as it ever was anyway).

When looking for this I also noticed we set link_bw to 270000, but the
calculation is different.  Does it also need to use kHz or we using
10kHz internally?
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

About 0.2W power can be saved on one HP laptop.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The hardware team suggest that the "large buffer" method should be
used to calculate the cursor watermark under non-SR state as well,
which is to avoid the flicker when FBC is enabled on Ironlake.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

In SR mode cursor plane watermark calculation uses same formula
like display plane. This one fixes the case for 965G and G45.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

The total self-refresh fifo entry size for display plane is 512
instead of 128 for 965G. Also fix WM value mask for 965G.

About 1.0W power can be saved on one T61 laptop after the self-refresh
watermark is configured correctly.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

For self-refresh mode WM calculation's "line time" should use
mode's htotal instead of hdisplay. "surface width" is the hdisplay
for display plane and 64 for cursor plane.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This one adds support for eDP that connected on PCH DP-D port
instead of CPU DP-A port, and only DP-D port could be used for eDP.

https://bugs.freedesktop.org/show_bug.cgi?id=27220Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NJan-Hendrik Zab <jan@jhz.name>
Tested-by: NTemplar <templar@rshc.de>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Ported over from the old UMS list.  Unfortunately they're still
necessary especially on older laptop platforms.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22126.
Tested-by: NXavier <shiningxc@gmail.com>
Tested-by: NDiego Escalante Urrelo <diegoe@gnome.org>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

The crtc mode fixup is run after the encoders adjust the mode to fit on
their output, so don't reset the mode!

Fixes:

  Bug 29057 - display corruption under 800x600 on netbook
              (1024x600) with 'Full Aspect' scaling
  https://bugs.freedesktop.org/show_bug.cgi?id=29057Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NXun Fang <xunx.fang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We're really supposed to do this to avoid trouble with underflows when
multiple planes are active.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=26987.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Nfangxun <xunx.fang@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This fixes a potential modesetting error during boot with plymouth on
Broadwater and Crestline introduced with 9df47c. The framebuffer was
hard-coding an alignment of 64K, but the modesetting code required the
documented alignment of 128K. The result was that we would attempt to
unbind the pinned fbcon buffer, triggering an ERROR and ultimately
failing the mode change.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

In some cases, unlocking the panel regs is safe and can help us avoid a
flickery, full mode set sequence.  So define the unlock key and use it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Fixes an Ironlake laptop with a 68.940MHz 1280x800 panel and 120MHz SSC
reference clock.

More generally, the 0.488% tolerance used before is just too tight to
reliably find a PLL setting.  I extracted the search algorithm and
modified it to find the dot clocks with maximum error over the valid
range for the given output type:

http://people.freedesktop.org/~ajax/intel_g4x_find_best_pll.c

This gave:

Worst dotclock for Ironlake DAC refclk is 350000kHz (error 0.00571)
Worst dotclock for Ironlake SL-LVDS refclk is 102321kHz (error 0.00524)
Worst dotclock for Ironlake DL-LVDS refclk is 219642kHz (error 0.00488)
Worst dotclock for Ironlake SL-LVDS SSC refclk is 84374kHz (error 0.00529)
Worst dotclock for Ironlake DL-LVDS SSC refclk is 183035kHz (error 0.00488)
Worst dotclock for G4X SDVO refclk is 267600kHz (error 0.00448)
Worst dotclock for G4X HDMI refclk is 334400kHz (error 0.00478)
Worst dotclock for G4X SL-LVDS refclk is 95571kHz (error 0.00449)
Worst dotclock for G4X DL-LVDS refclk is 224000kHz (error 0.00510)
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

We cannot the initial configuration set by the BIOS not to have a dither
mode enabled which conflicts with our enabling the Spatial Temporal 1
dither mode for PCH. In particular, the BIOS may either enable temporal
dithering or the Spatial Temporal 2 with the result that we enable pure
temporal dithering. Temporal dithering looks bad and is perceived as a
flicker.

Fixes:

  Bug 29248 - [Arrandale] Annoying flicker on internal panel, goes away
              after suspend to RAM
  https://bugs.freedesktop.org/show_bug.cgi?id=29248Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

If a framebuffer is shared across CRTCs, the x,y position of one of them
is likely to be something other than the origin (e.g. for extended
desktop configs).  So calculate the offset at flip time so such
configurations can work.

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28518.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NThomas M. <tmezzadra@gmail.com>
Tested-by: Nfangxun <xunx.fang@intel.com>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The register offset for FW_BLC_SELF is a totally different set of bits
on Broadwater (it's actually MI_RDRET_STATE), so don't treat it like
FW_BLC_SELF on 965G chips.

Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=26874.

Cc: stable@kernel.org
Tested-by: NNorman Yarvin <yarvin@yarchive.net>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Gen3 chips have slightly different flip commands, and also contain a bit
that indicates whether a "flip pending" interrupt means the flip has
been queued or has been completed.

So implement support for the gen3 flip command, and make sure we use the
flip pending interrupt correctly depending on the value of ECOSKPD bit
0.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Hardware will set the flip pending ISR bit as soon as it receives the
flip instruction, and (supposedly) clear it once the flip completes
(e.g. at the next vblank).  If we try to send down a flip instruction
while the ISR bit is set, the hardware can become very confused, and we
may never receive the corresponding flip pending interrupt, effectively
hanging the chip.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Enable self-refresh on 945 when just one CRTC is activated.
Otherwise user would get display flicker with dual display.

This fixes https://bugs.freedesktop.org/show_bug.cgi?id=27667Signed-off-by: NLi Peng <peng.li@intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This reverts commit cfecde43, since it
seems to cause some systems to not come up with any video output at all
(or video that only comes on when X starts up).

Fixes bugzilla:

    http://bugzilla.kernel.org/show_bug.cgi?id=16163Reported-and-tested-by: NDavid John <davidjon@xenontk.org>
Tested-by: NNick Bowler <nbowler@elliptictech.com>
Acked-by: NCarl Worth <cworth@cworth.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

(regression fix since fbdev/kms rework).

My fb rework didn't remember about the 84/65s.
Reported-by: NOndrej Zary <linux@rainbow-software.org>
Tested-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Cursors need to be in the GTT domain when being accessed by the GPU.
Previously this was a fortuitous byproduct of userspace using pwrite()
to upload the image data into the cursor. The redundant clflush was
removed in commit 9b8c4a and so the image was no longer being flushed
out of the caches into main memory. One could also devise a scenario
where the cursor was rendered by the GPU, prior to being attached as the
cursor, resulting in similar corruption due to the missing MI_FLUSH.

Fixes:

  Bug 28335 - Cursor corruption caused by commit 9b8c4a0b
  https://bugs.freedesktop.org/show_bug.cgi?id=28335Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: NJeff Chua <jeff.chua.linux@gmail.com>
Tested-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NAndy Isaacson <adi@hexapodia.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Cursors need to be in the GTT domain when being accessed by the GPU.
Previously this was a fortuitous byproduct of userspace using pwrite()
to upload the image data into the cursor. The redundant clflush was
removed in commit 9b8c4a and so the image was no longer being flushed
out of the caches into main memory. One could also devise a scenario
where the cursor was rendered by the GPU, prior to being attached as the
cursor, resulting in similar corruption due to the missing MI_FLUSH.

Fixes:

  Bug 28335 - Cursor corruption caused by commit 9b8c4a0b
  https://bugs.freedesktop.org/show_bug.cgi?id=28335Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NArkadiusz Miśkiewicz <arekm@maven.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>

This reverts commit cfecde43.

The commit was first created as an attempt to fix LVDS initialiazation
on Ironlake. Testing revealed that it didn't fix that, but it was
assumed to still be correct anyway.

Subsequent testing has revealed that this commit has caused other
regressions:

  * Change in VBlank interrupt frequency causing 60% 3D performance regression
    http://bugs.freedesktop.org/show_bug.cgi?id=27698

  * Black screen on G45
    http://bugs.freedesktop.org/show_bug.cgi?id=27733

So revert this buggy code for now to revisit later when we can fix
actual bugs without causing these regressions.
Signed-off-by: NCarl Worth <cworth@cworth.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Add the pitch that we about to write into the control register along
with the base, offset and coordinates that go into the other control
registers.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

If the FBC is already disabled, then we do not even attempt to disable
FBC and so there is no point emitting a debug statement at that point,
having already emitted one saying why we are disabling FBC.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Delay taking the mutex until we need to and ensure that we hold the
spinlock when resetting unpin_work on the error path. Also defer the
debugging print messages until after we have released the spinlock.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Pineview with DDR3 memory has different latencies to enable CxSR.
This patch updates CxSR latency table to add Pineview DDR3 latency
configuration. It also adds one flag "is_ddr3" for checking DDR3
setting in MCHBAR.

Cc: Shaohua Li <shaohua.li@intel.com>
Cc: Zhao Yakui <yakui.zhao@intel.com>
Signed-off-by: NLi Peng <peng.li@intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

We can, by virtue of a vblank interrupt firing in the middle of setting
up the unpin work (i.e. after we set the unpin_work field and before we
write to the ringbuffer) enter intel_finish_page_flip() prior to
receiving the pending flip notification. Therefore we can expect to hit
intel_finish_page_flip() under normal circumstances without a pending flip
and even without installing the pending_flip_obj. This is exacerbated by
aperture thrashing whilst binding the framebuffer

References:

  Bug 28079 - "glresize" causes kernel panic in intel_finish_page_flip.
  https://bugs.freedesktop.org/show_bug.cgi?id=28079Reported-by: NNick Bowler <nbowler@draconx.ca>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: stable@kernel.org
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Add power monitoring support to the i915 driver for use by the IPS
driver.  Export the available power info to the IPS driver through a few
new inter-driver hooks.  When used together, the IPS driver and this
patch can significantly increase graphics performance on Ironlake class
chips.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: Fixed 32-bit compile.  stupid obfuscating div_u64()]
Signed-off-by: NEric Anholt <eric@anholt.net>

This doesn't change the clock limits (minimums), i.e. it won't make it
output 720x576 PAL nor 720x480 NTSC, but it will work with modes like
1080i etc. (including GLX and textured Xvideo, not sure about the
overlay).

Tested on i915 + analog VGA, it would be worth checking if newer chips
(and which ones) still support interlaced mode.
Signed-off-by: NKrzysztof Halasa <khc@pm.waw.pl>
Signed-off-by: NEric Anholt <eric@anholt.net>