0
0
mirror of https://mirrors.bfsu.edu.cn/git/linux.git synced 2024-12-22 10:34:55 +08:00
Commit Graph

413395 Commits

Author SHA1 Message Date
Ben Widawsky
ab57fff130 drm/i915/bdw: Implement ff workarounds
WaVSRefCountFullforceMissDisable and
WaDSRefCountFullforceMissDisable

VS is a carry-over from HSW, and DS is likely not used by anyone yet.

Cc: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Line of 106 chars is too long. Really.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13 17:55:54 +01:00
Ben Widawsky
63801f211c drm/i915/bdw: Force all Data Cache Data Port access to be Non-Coherent
I stumbled on to some unimplemented errata. To be honest, I am not
really sure of the impact, just that the docs say to do.

No w/a name for this one.

v2: v1 was a stale thing which should have never seen the light of day.
(Haihao)

Cc: Kenneth Graunke <kenneth@whitecape.org>
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>
2013-12-13 17:51:24 +01:00
Ville Syrjälä
a3564d2b52 drm/i915/bdw: Don't use forcewake needlessly
Not all registers need forcewake even if they're not shadowed.
Add the missing check to gen8_writeX() to avoid needless forcewake
usage when writing eg. display registers.

v2: Use straight up <0x40000 check instead of NEEDS_FORCE_WAKE()

Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-13 17:48:28 +01:00
Ville Syrjälä
97058870e6 drm/i915: Clear out old GT FIFO errors in intel_uncore_early_sanitize()
The BIOS or someone else might have done something bad and there
might be old GT FIFO erros reported in GTFIFODBG. Clear those out
in intel_uncore_early_sanitize() to make sure we don't mistake them
for our problems.

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>
2013-12-13 10:41:06 +01:00
Mika Kuoppala
168c3f2151 drm/i915: dont call irq_put when irq test is on
If test is running, irq_get was not called so we should gain
balance by not doing irq_put

"So the rule is: if you access unlocked values, you use ACCESS_ONCE().
You don't say "but it can't matter". Because you simply don't know."
-- Linus

v2: use local variable so it can't change during test (Chris)

v3: update commit msg and use ACCESS_ONCE (Ville)

Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 22:58:44 +01:00
Ville Syrjälä
993495ae99 drm/i915: Rework the FBC interval/stall stuff a bit
Don't touch DPFC_RECOMP_CTL on FBC2, use RMW to update
the FBC_CONTROL on FBC1 to make it easier for people to
experiment with different numbers. Also fix the interval
mask for FBC1.

v2: Rebased

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 22:58:42 +01:00
Ville Syrjälä
fd70d52acc drm/i915: Enable FBC for all mobile gen2 and gen3 platforms
All mobile gen2 and gen3 chipsets should have FBC1, and the code
should now handle them all. So just set has_fbc=true for all such
chipsets.

Note that fbc is still disabled by default for now.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 16:03:41 +01:00
Ville Syrjälä
159f98750e drm/i915: FBC_CONTROL2 is gen4 only
Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't
touch it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 15:58:09 +01:00
Ville Syrjälä
42a430f51c drm/i915: Gen2 FBC1 CFB pitch wants 32B units
On gen2 the compressed frame buffer pitch is specified in 32B units
rather than the 64B units used on gen3+.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 15:57:47 +01:00
Paulo Zanoni
566b734a19 drm/i915: split intel_ddi_pll_mode_set in 2 pieces
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Bikeshed comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 15:30:47 +01:00
Mika Kuoppala
47e9766df0 drm/i915: Fix timeout with missed interrupts in __wait_seqno
Commit 094f9a54e3 ("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: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 15:27:21 +01:00
Paulo Zanoni
f9dcb0dfee drm/i915: touch VGA MSR after we enable the power well
Fixes regression introduced by:
    commit bf51d5e2cd
    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 . 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=67813
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 13:28:37 +01:00
Paulo Zanoni
d5e8fdc8c1 drm/i915: extract hsw_power_well_post_{enable, disable}
I want to add more code to the post_enable function.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 13:28:22 +01:00
Paulo Zanoni
b664607480 drm/i915: remove i915_disable_vga_mem declaration
It was supposed to have been killed on the same commit that killed the
function, e1264ebe9f, but I guess the
intel_drv.h reorganization accidentally brought it back.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-12 13:28:10 +01:00
Shobhit Kumar
f6da28429a drm/i915: Parametrize the dphy and other spec specific parameters
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: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:20 +01:00
Shobhit Kumar
a4a593be5d drm/i915: Remove redundant DSI PLL enabling
DSI PLL will get configured during crtc_enable using ->pre_pll_enable
and no need to do in ->mode_set

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:20 +01:00
Shobhit Kumar
1dbd7cb256 drm/i915: Reorganize the DSI enable/disable sequence
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: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:19 +01:00
Shobhit Kumar
8e1eed5aa8 drm/i915: Try harder to get best m, n, p values with minimal error
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: Vijayakumar Balakrishnan <vijayakumar.balakrishnan@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:18 +01:00
Shobhit Kumar
44d4c6eebb drm/i915: Compute dsi_clk from pixel clock
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: Vijayakumar Balakrishnan <vijayakumar.balakrishnan@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:18 +01:00
Shobhit Kumar
e9fe51c665 drm/i915: Use FLISDSI interface for band gap reset
v2: Rebased on latest code

Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Reviewed-by: Jani Nikula<jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:17 +01:00
Shobhit Kumar
b9f5e07d02 drm/i915: Add more dev ops for MIPI sub encoder
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: Yogesh Mohan Marimuthu <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:16 +01:00
Ville Syrjälä
9c333719ae drm/i915: Decrease gen2 vco frequency minimum to 908 MHz
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:16 +01:00
Ville Syrjälä
e91e941bd5 drm/i915: Fix 66 MHz LVDS SSC freq for gen2
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:15 +01:00
Ville Syrjälä
c7721d3266 drm/i915: Increase gen2 vco frequency limit to 1512 MHz
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:14 +01:00
Ville Syrjälä
91dbe5fb77 drm/i915: Change N divider minimum from 3 to 2 for gen2
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:14 +01:00
Ville Syrjälä
b1c560d13d drm/i915: Extract p2 divider correctly for gen2 LVDS dual channel
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:13 +01:00
Ville Syrjälä
3dda20a974 drm/i915: Record BB_ADDR for every ring
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:12 +01:00
Ville Syrjälä
0476190e10 drm/i915: Use 32bit read for BB_ADDR
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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:12 +01:00
Paulo Zanoni
90791a5c64 drm/i915: fix VDD override off wait
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:52:11 +01:00
Paulo Zanoni
dff392dbd2 drm/i915: don't touch the VDD when disabling the panel
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=69693
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo 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: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-11 23:51:41 +01:00
Paulo Zanoni
9b33600d52 drm/i915: don't enable VDD just to enable the panel
We just don't need this. This saves 250ms from every modeset on my
machine.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 23:13:09 +01:00
Paulo Zanoni
8771a7f802 drm/i915: add runtime PM support on Haswell
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Don't actually enable runtime pm since I didn't merge all
patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 23:08:34 +01:00
Paulo Zanoni
1f2d453199 drm/i915: disable interrupts when enabling PC8
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:56:34 +01:00
Paulo Zanoni
6806e63f48 drm/i915: do not assert DE_PCH_EVENT_IVB enabled
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo 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: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:54:44 +01:00
Paulo Zanoni
e9cb81a228 drm/i915: get a runtime PM reference when the panel VDD is on
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:50:42 +01:00
Paulo Zanoni
c8c8fb33b3 drm/i915: add some runtime PM get/put calls
These are needed when we cat the debugfs and sysfs files.

V2: - Rebase
V3: - Rebase
V4: - Rebase

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>
2013-12-10 22:50:17 +01:00
Paulo Zanoni
f65c916898 drm/i915: add runtime put/get calls at the basic places
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Drop the hunk in i915_hangcheck_elapsed, it's the wrong thing
to do.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:47:33 +01:00
Paulo Zanoni
cd2e9e908a drm/i915: do adapter power state notification at runtime PM
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:44:00 +01:00
Paulo Zanoni
8a1874559f drm/i915: add initial Runtime PM functions
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:43:14 +01:00
Paulo Zanoni
d62292c8f7 drm/i915: get a PC8 reference when enabling the power well
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:27:16 +01:00
Paulo Zanoni
7125ecb829 drm/i915: WARN if !HAS_PC8 when enabling/disabling PC8
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 22:26:33 +01:00
Ville Syrjälä
8212d56329 drm/i915: Move VLV PHY CRI clock enable into intel_init_dpio()
The CRI clock is related to the display PHY, so the setup belongs
in intel_init_dpio().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 20:04:58 +01:00
Ville Syrjälä
fff6386766 drm/i915: Don't cast away const from infoframe buffer
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: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 14:49:04 +01:00
Vandana Kannan
ec9ed1976c drm/i915: Make downclock deduction common for all panels
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: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-10 13:26:15 +01:00
Deepak S
c461562e84 drm/i915: Remove duplicate intel_uncore_forcewake_reset.
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 ef46e0d247
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 521198a2e7
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: Deepak S <deepak.s@intel.com>
[danvet: Explain how this came to be.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-09 09:25:14 +01:00
Daniel Vetter
f7698ba75f Linux 3.13-rc3
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.15 (GNU/Linux)
 
 iQEcBAABAgAGBQJSogqUAAoJEHm+PkMAQRiGM2MIAJrr5KEXEWuuAR4+JkkWBK7A
 +dVT4n1MM4wP/aCIyriSlq7kgT03Wxk4Q4wKsj2wZvDQkNgEQjrctgIihc75jqi5
 126nmT3YXJLwgDpFA3RHZUWve3j3vfUG53rRuk7K9Xx1sGWU3Ls7BuInvQZ//+QS
 6UB4UuEAalmose5U8ToXQfMqZhjwreZKeb64TEZwFvu2klv4cnka1L/zHbmQGgRg
 2Pfv+aUrjsYE8s9lkEKX8MIQsDn28Q5Lsv7XIEQwo2at4rYbJaxX6usuC1OI0MQ5
 BLUn1GgtvOidq6FzSg6kXiA/MJYH3J0S+p4uULWAprxA+KeJRbWNRroM94W1qAk=
 =1Wcq
 -----END PGP SIGNATURE-----

Merge tag 'v3.13-rc3' into drm-intel-next-queued

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: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-09 09:19:14 +01:00
Paulo Zanoni
798183c547 drm/i915: change CRTC assertion on LCPLL disable
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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-06 23:37:12 +01:00
Linus Torvalds
374b105797 Linux 3.13-rc3 2013-12-06 09:34:04 -08:00
Linus Torvalds
843f4f4bb1 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.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.15 (GNU/Linux)
 
 iQEcBAABAgAGBQJSofYNAAoJEKQekfcNnQGuTUcIAJOx8745KlkFjN4VX+nCWNfP
 xrrpnLBymbGMA9lQ4fXk+kdiuhH8DjRYdKq9fU4T481MFYKkToUIZH6NeaLI5fr1
 0nBPPjVyAlJ+yt9JbOAYa1jEYnAr27ORDHEtdQnqb6OJSky3oh9jCQi+toxmh2qX
 Sv1tIYeAf3K2V/h5xt6uSl9oiZ6KBtwE3f+xkHWNizaU9i2rq2gxd77fSbPNTIps
 wLdsESYziA2UeAm13eh8xXo1uqRbfvx7bPr59cu0+3AqdOoaXFG+JoE/MqmljIO5
 HkyCKJVqP8HD+QieuEB+hw4zpSsl6A6iKSlaiHm8NMnRRocfM6qMKMQXQ28KhxA=
 =sYm/
 -----END PGP SIGNATURE-----

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
2013-12-06 08:34:16 -08:00
Linus Torvalds
c537aba00e Merge git://git.kvack.org/~bcrl/aio-next
Pull aio fix from Benjamin LaHaise:
 "AIO fix from Gu Zheng that fixes a GPF that Dave Jones uncovered with
  trinity"

* git://git.kvack.org/~bcrl/aio-next:
  aio: clean up aio ring in the fail path
2013-12-06 08:32:59 -08:00