The first piece, intel_ddi_pll_select, finds a PLL and assigns it to
the CRTC, but doesn't write any register. It can also fail in case it
doesn't find a PLL.

The second piece, intel_ddi_pll_enable, uses the information stored by
intel_ddi_pll_select to actually enable the PLL by writing to its
register. This function can't fail. We also have some refcount sanity
checks here.

The idea is that one day we'll remove all the functions that touch
registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll
call intel_ddi_pll_select at haswell_crtc_mode_set and then call
intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already
touching this code, let's take care of this particular split today.

v2: - Clock on the debug message is in KHz
    - Add missing POSTING_READ
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Bikeshed comments.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 094f9a54 ("drm/i915: Fix __wait_seqno to use true infinite
timeouts") added support for __wait_seqno to detect missing interrupts and
go around them by polling. As there is also timeout detection in
__wait_seqno, the polling and timeout detection were done with the same
timer.

When there has been missed interrupts and polling is needed, the timer is
set to trigger in (now + 1) jiffies in future, instead of the caller
specified timeout.

Now when io_schedule() returns, we calculate the jiffies left to timeout
using the timer expiration value. As the current jiffies is now bound to be
always equal or greater than the expiration value, the timeout_jiffies will
become zero or negative and we return -ETIME to caller even tho the
timeout was never reached.

Fix this by decoupling timeout calculation from timer expiration.

v2: Commit message with some sense in it (Chris Wilson)

v3: add parenthesis on timeout_expire calculation

v4: don't read jiffies without timeout (Chris Wilson)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixes regression introduced by:
    commit bf51d5e2
    Author: Paulo Zanoni <paulo.r.zanoni at intel.com>
    Date:   Wed Jul 3 17:12:13 2013 -0300
        drm/i915: switch disable_power_well default value to 1

The bug I'm seeing can be reproduced with:
  - Have vgacon configured/enabled
  - Make sure the power well gets disabled, then enabled. You can
    check this by seeing the messages print by hsw_set_power_well
  - Stop your display manager
  - echo 0 > /sys/class/vtconsole/vtcon1/bind

I can easily reproduce this by blacklising snd_hda_intel and booting
with eDP+HDMI.

If you do this and then look at dmesg, you'll see we're printing
infinite "Unclaimed register" messages. This is happening because
we're stuck on an infinite loop inside console_unlock(), which is
calling many functions from vgacon.c. And the code that's triggering
the error messages is from vgacon_set_cursor_size().

After we re-enable the power well, every time we read/write the VGA
address 0x3d5 we get an "unclaimed register" interrupt (ERR_INT) and
print error messages. If we write anything to the VGA MSR register (it
doesn't really matter which value you write to bit 0), any
reads/writes to 0x3d5 _don't_ trigger the "unclaimed register" errors
anymore (even if MSR bit 0 is zero). So what happens with the current
code is that when we unbind i915 and bind vgacon, we call
console_unlock(). Function console_unlock() is responsible for
printing any messages that were supposed to be print when the console
was locked, so it calls the TTY layer, which calls the console layer,
which calls vgacon to print the messages. At this point, vgacon
eventually calls vgacon_set_cursor_size(), which touches 0x3d5, which
triggers unclaimed register interrupts. The problem is that when we
get these interrupts, we print the error messages, so we add more work
to console_unlock(), which will try to print it again, and then call
vgacon again, trigger a new interrupt, which will put more stuff to
the buffer, and then we'll be stuck at console_unlock() forever.

If you patch intel_uncore.c to not print anything when we detect
unclaimed registers, we won't get into the console_unlock() infinite
loop and the driver unbind will work just fine. We will still be
getting interrupts every time vgacon touches those registers, but we
will survive. This is a valid experiment, but IMHO it's not the real
fix: if we don't print any error messages we will still keep getting
the interrupts, and if we disable ERR_INT we won't get the interrupt
anymore, but we will also stop getting all the other error interrupts.

I talked about this problem with the HW engineer and his
recommendation is "So don't do any VGA I/O or memory access while the
power well is disabled, and make to re-program MSR after enabling the
power well and before using VGA I/O or memory accesses.".

Notice that this is just a partial fix to fd.o #67813. This fixes the
case where the power well is already enabled when we unbind, not when
it's disabled when we unbind.

V2: - Rebase (first version was sent in September).
V3: - Complete rewrite of the same fix: smaller implementation,
      improved commit message.

Testcase: igt/drv_module_reload
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67813Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I want to add more code to the post_enable function.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It was supposed to have been killed on the same commit that killed the
function, e1264ebe, but I guess the
intel_drv.h reorganization accidentally brought it back.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The values of these parameters will be different for differnet panel
based on dsi rate, lane count, etc. Remove the hardcodings and make
these as parameters whch will be initialized in panel specific
sub-encoder implementaion.

This will also form groundwork for planned generic panel sub-encoder
implemntation based on VBT design enhancments to support multiple panels

v2: Mask away the port_bits before use
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

DSI PLL will get configured during crtc_enable using ->pre_pll_enable
and no need to do in ->mode_set
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Basically ULPS handling during enable/disable has been moved to
pre_enable and post_disable phases. PLL and panel power disable
also has been moved to post_disable phase. The ULPS entry/exit
sequneces as suggested by HW team is as follows -

During enable time -
set DEVICE_READY --> Clear DEVICE_READY --> set DEVICE_READY

And during disable time to flush all FIFOs -
set ENTER_SLEEP --> EXIT_SLEEP --> ENTER_SLEEP

Also during disbale sequnece sub-encoder disable is moved to the end
after port is disabled.

v2: Based on comments from Ville
    - Detailed epxlaination in the commit messgae
    - Moved parameter changes out into another patch
    - Backlight enabling will be a new patch

v3: Updated as per Jani's comments
    - Removed the I915_WRITE_BITS as it is not needed
    - Moved panel_reset and send_otp_cmds hooks to dsi_pre_enable
    - Moved disable_panel_power hook to dsi_post_disable
    - Replace hardcoding with AFE_LATCHOUT

v4: Make intel_dsi_device_ready and intel_dsi_clear_device_ready static
Signed-off-by: NYogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Basically check for both +ive and -ive deviation from target clock and
pick the one with minimal error. If we get a direct match, break from
loop to acheive some optimization.

v2: Use signed variable for target and calculated dsi clock values
Signed-off-by: NVijayakumar Balakrishnan <vijayakumar.balakrishnan@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pixel clock based calculation is recommended in the MIPI host controller
documentation

v2: Based on review comments from Jani and Ville
    - Use dsi_clk in KHz rather than converting in Hz and back to MHz
    - RR formula is retained though not used but return dsi_clk in KHz now
    - Moved the m-n-p changes into a separate patch
    - Removed the parameter check for intel_dsi->dsi_clock_freq. This will be
      bought back in if needed when appropriate panel drivers are done

v3: Removed the unused mnp calculation from static table
Signed-off-by: NVijayakumar Balakrishnan <vijayakumar.balakrishnan@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Rebased on latest code
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NYogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Reviewed-by: Jani Nikula<jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some panels require one time programming if they do not contain their
own eeprom for basic register initialization. The sequence is

Panel Reset --> Send OTP --> Enable Pixel Stream --> Enable the panel

v2: Based on review comments from Jani and Ville
    - Updated the commit message with more details
    - Move the new parameters out of this patch
Signed-off-by: NYogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On my 855 machine the BIOS uses the following DPLL settings:
DPLL 0x90016000
FP0 = 0x61207
FP1 = 0x21207

With the 66MHz SSC refclock, that puts the BIOS generated VCO
frequency at ~908 MHz, which is lower than the 930 MHz limit
we have currently. This also results in the pixel clock coming
out significantly higher than the requested 65 MHz when we try
to recompute it.

Reduce the the VCO limit to 908 MHz. Combined with the earlier
SSC reference clock accuracy fix, this results in the pixel clock
coming out as 65.08 MHz which is quite close to the target. For
some reason the BIOS uses 64.881 MHz, which isn't quite as close.

This makes kms_flip wf_vblank-ts-check pass for the first time
on this machine \o/

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Store the SSC refclock frequency in kHz to get more accuracy. Currently
we're pretending that 66 MHz is ~66000 kHz, when in fact it is actually
~66667 kHz. By storing the less rounded kHz value we get a much better
accuracy for out pixel clock calculations.

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.

The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa

The BIOS uses the following DPLL settings:
DPLL = 0x90020000
FP0 = 0x2140e
FP1 = 0x21207

That puts the BIOS generated VCO frequency at 1512 MHz, which is
higher than the 1400 MHz limit we have currently.

Let's bump the VCO limit to 1512 MHz and see what happens.

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bruno Prémont has a 855 machine with a 1400x1050 LVDS screen.

The VBT mode is as follows:
0:"1400x1050" 0 108000 1400 1416 1528 1688 1050 1051 1054 1066 0x8 0xa

The BIOS uses the following DPLL settings:
DPLL = 0x90020000
FP0 = 0x2140e
FP1 = 0x21207

We can't generate that pixel clock currently as we're limiting the N
divider to at least 3, whereas the BIOS uses a value of 2.

Let's reduce the N minimum to 2 and see what happens.

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to determine the correct p2 divider for LVDS on gen2,
we need to check the CLKB mode from the LVDS port register to
determine if we're dealing with single or dual channel LVDS.

Cc: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NBruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Every ring seems to have a BB_ADDR registers, so include them all in the
error state.

v2: Also include the _UDW on BDW
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The BB_ADDR register is documented to be 32bits at least since SNB.
Prior to that the high 32bits were listed as MBZ, so using a 64bit read
doesn't seem worth anything. Also the simulator doesn't like the 64bit
read. So just switch to using a 32bit read instead.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we're disabling the VDD override bit and the panel is enabled, we
don't need to wait for anything. If the panel is disabled, then we
need to actually wait for panel_power_cycle_delay, not
panel_power_down_delay, because the power down delay was already
respected when we disabled the panel.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo.
Also drop the runtime_pm_put call which now has to go due to different
patch ordering. Also from Paul.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We just don't need this. This saves 250ms from every modeset on my
machine.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The code to enable/disable PC8 already takes care of saving and
restoring all the registers we need to save/restore, so do a put()
call when we enable PC8 and a get() call when we disable it.

Ideally, in order to make it easier to add runtime PM support to other
platforms, we should move some things from the PC8 code to the runtime
PM code, but let's do this later, since we can make Haswell work right
now.

V2: - Rebase
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Don't actually enable runtime pm since I didn't merge all
patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The plan is to merge PC8 and D3 into a single feature, and when we're
in D3 we won't get any hotplug interrupt anyway, so leaving them
enable doesn't make sense, and it also brings us a problem. The
problem is that we get a hotplug interrupt right when we we wake up
from D3, when we're still waking up everything. If we fully disable
interrupts we won't get this hotplug interrupt, so we won't have
problems.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current code was checking if all bits of "val" were enabled and
DE_PCH_EVENT_IVB was disabled. The new code doesn't care about the
state of DE_PCH_EVENT_IVB: it just checks if everything else is 1.

The goal is that future patches may completely disable interrupts, and
the LCPLL-disabling code shouldn't care about the state of
DE_PCH_EVENT_IVB.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: I think the commit message is actually wrong in it's
description of what the old test checked, but the new one seems sane.
So meh.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And put it when it's off. Otherwise, when you run pm_pc8 from
intel-gpu-tools, and the delayed function that disables VDD runs,
we'll get some messages saying we're touching registers while the HW
is suspended.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These are needed when we cat the debugfs and sysfs files.

V2: - Rebase
V3: - Rebase
V4: - Rebase
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If I add code to enable runtime PM on my Haswell machine, start a
desktop environment, then enable runtime PM, these functions will
complain that they're trying to read/write registers while the
graphics card is suspended.

v2: - Simplify i915_gem_fault changes.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Drop the hunk in i915_hangcheck_elapsed, it's the wrong thing
to do.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that we are actually setting the device to the D3 state, we should
issue the notification.

The opregion spec says we should send the message before the adapter
is about to be placed in a lower power state, and after the adapter is
placed in a higher power state.

Jani originally wrote a similar patch for PC8, but then we discovered
that we were not really changing the PCI D states when
enabling/disabling PC8, so we had to postpone his patch.

v2: - Improve commit message, explaining the expected state.

v3: - Rebase.

Cc: Jani Nikula <jani.nikula@intel.com>
Credits-to: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch adds the initial infrastructure to allow a Runtime PM
implementation that sets the device to its D3 state. The patch just
adds the necessary callbacks and the initial infrastructure.

We still don't have any platform that actually uses this
infrastructure, we still don't call get/put in all the places we need
to, and we don't have any function to save/restore the state of the
registers. This is not a problem since no platform uses the code added
by this patch. We have a few people simultaneously working on runtime
PM, so this initial code could help everybody make their plans.

V2: - Move some functions to intel_pm.c
    - Remove useless pm_runtime_allow() call at init
    - Remove useless pm_runtime_mark_last_busy() call at get
    - Use pm_runtime_get_sync() instead of 2 calls
    - Add a WARN to check if we're really awake

V3: - Rebase.

V4: - Don't need to call pci_{save,restore}_state and
      pci_set_power_sate, since they're already called by the PCI
      layer
    - Remove wrong pm_runtime_enable() call at init_runtime_pm
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the current code, at haswell_modeset_global_resources, first we
decide if we want to enable/disable the power well, then we decide if
we want to enable/disable PC8. On the case where we're enabling PC8
this works fine, but on the case where we disable PC8 due to a non-eDP
monitor being enabled, we first enable the power well and then disable
PC8. Although wrong, this doesn't seem to be causing any problems now,
and we don't even see anything in dmesg. But the patches for runtime
D3 turn this problem into a real bug, so we need to fix it.

This fixes the "modeset-non-lpsp" subtest from the "pm_pc8" test from
intel-gpu-tools.

v2: - Rebase (i915_disable_power_well).
v3: - More reabase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already have some checks and shouldn't be reaching these places on
!HAS_PC8 platforms, but add a WARN,  just in case.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The CRI clock is related to the display PHY, so the setup belongs
in intel_init_dpio().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't modify the packed infoframe data, so we should keep the
const qualifier in place. Just pass the buffer as 'const void *'
instead of 'const uint8_t *' and we can drop the cast entirely.

v2: Do intel_sdvo_write_infoframe() as well
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If one mode of a internal panel has more than one refresh rate, then a reduced
clock is found for the LFP (LVDS/eDP). This enables switching between low
and high frequency dynamically. Moving downclock calculation to intel_panel
so that it is common for LVDS and eDP.
Signed-off-by: NVandana Kannan <vandana.kannan@intel.com>
Signed-off-by: NPradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since early sanitize and uncore sanitize are called one after the other,
I think, we can remove second forcewake reset which was are calling
twice in both the functions.

Note that this is merge fallout between

commit ef46e0d2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat Nov 16 16:00:09 2013 +0100

    drm/i915: restore the early forcewake cleanup

and

commit 521198a2
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Fri Aug 23 16:52:30 2013 +0300

    drm/i915: sanitize forcewake registers on reset
Signed-off-by: NDeepak S <deepak.s@intel.com>
[danvet: Explain how this came to be.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Linux 3.13-rc3

I need a backmerge for two reasons:
- For merging the ppgtt patches from Ben I need to pull in the bdw
  support.
- We now have duplicated calls to intel_uncore_forcewake_reset in the
  setup code to due 2 different patches merged into -next and 3.13.
  The conflict is silen so I need the merge to be able to apply
  Deepak's fixup patch.

Conflicts:
	drivers/gpu/drm/i915/intel_display.c

Trivial conflict, it doesn't even show up in the merge diff.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently, PC8 is enabled at modeset_global_resources, which is called
after intel_modeset_update_state. Due to this, there's a small race
condition on the case where we start enabling PC8, then do a modeset
while PC8 is still being enabled. The racing condition triggers a WARN
because intel_modeset_update_state will mark the CRTC as enabled, then
the thread that's still enabling PC8 might look at the data structure
and think that PC8 is being enabled while a pipe is enabled. Despite
the WARN, this is not really a bug since we'll wait for the
PC8-enabling thread to finish when we call modeset_global_resources.

The spec says the CRTC cannot be enabled when we disable LCPLL, so we
had a check for crtc->base.enabled. If we change to crtc->active we
will still prevent disabling LCPLL while the CRTC is enabled, and we
will also prevent the WARN above.

This is a replacement for the previous patch named
    "drm/i915: get/put PC8 when we get/put a CRTC"

Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Merge tag 'trace-fixes-3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing fix from Steven Rostedt:
 "A regression showed up that there's a large delay when enabling all
  events.  This was prevalent when FTRACE_SELFTEST was enabled which
  enables all events several times, and caused the system bootup to
  pause for over a minute.

  This was tracked down to an addition of a synchronize_sched()
  performed when system call tracepoints are unregistered.

  The synchronize_sched() is needed between the unregistering of the
  system call tracepoint and a deletion of a tracing instance buffer.
  But placing the synchronize_sched() in the unreg of *every* system
  call tracepoint is a bit overboard.  A single synchronize_sched()
  before the deletion of the instance is sufficient"

* tag 'trace-fixes-3.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Only run synchronize_sched() at instance deletion time