- 13 Dec, 2013 2 commits
-
-
Ville Syrjälä authored
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>
-
Ville Syrjälä authored
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:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 12 Dec, 2013 10 commits
-
-
Mika Kuoppala authored
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ä authored
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ä authored
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ä authored
Gen2 and gen3 don't have the FBC_CONTROL2 register, so don't touch it. Signed-off-by:
-
Ville Syrjälä authored
On gen2 the compressed frame buffer pitch is specified in 32B units rather than the 64B units used on gen3+. Signed-off-by:
-
Paulo Zanoni authored
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:
-
Mika Kuoppala authored
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:
-
Paulo Zanoni authored
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: -
Paulo Zanoni authored
I want to add more code to the post_enable function. Signed-off-by:
-
Paulo Zanoni authored
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:
-
- 11 Dec, 2013 16 commits
-
-
Shobhit Kumar authored
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:
-
Shobhit Kumar authored
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 authored
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 authored
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 authored
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: -
Shobhit Kumar authored
v2: Rebased on latest code Signed-off-by:
-
Shobhit Kumar authored
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: -
Ville Syrjälä authored
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:
Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
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:
-
Paulo Zanoni authored
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Paulo Zanoni authored
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:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
- 10 Dec, 2013 12 commits
-
-
Paulo Zanoni authored
We just don't need this. This saves 250ms from every modeset on my machine. Reviewed-by:
-
Paulo Zanoni authored
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 authored
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 authored
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 authored
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 authored
These are needed when we cat the debugfs and sysfs files. V2: - Rebase V3: - Rebase V4: - Rebase Signed-off-by:
-
Paulo Zanoni authored
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 authored
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 authored
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 authored
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 authored
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:
-
Ville Syrjälä authored
The CRI clock is related to the display PHY, so the setup belongs in intel_init_dpio(). Signed-off-by:
-
