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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-----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>
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>
If we force the hw to idle as our first step during unload, we can abort
the unload upon failure. Later we can probe whether the hardware remain
active even after we try to shut it down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Doing it early prevents moving and relocating objects in vain
for contexts that won't get any GPU time.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It is useful to assert that if the object is bound, then it must have
its pages pinned to prevent the shrinker from reaping its backing store.
This is even more useful with the introduction of real-ppgtt whereupon
we may have the object bound into several vma, with each instance
pinning the backing store. This assertion breaks down during unbind
where we unpinned the backing store before decoupling the vma binding.
This can be fixed with a trivial reording of the unbind sequence, which
reinforces the
pin pages
bind to vma
...
unbind from vma
unpin pages
concept.
v2: Bonus comment
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV, FIFO will be shared by both SW and HW. So, we read the
free entries through register and update dev_priv variable
and wait for only 20 entries to be free
From Deepak's follow-up mail explaining why vlv is special:
"On SB, Out of 64 FIFO Entries, 20 Entries will be used by HW and
remaining 44 will be used by the SW,. I think due to this reason, we
have a threshold of 20 Entries."
"On VLV, HW and SW can access all 64 fifo entries, I don't think
having a threshold of 20 Entries is mandatory on VLV. Also, since both
SW and HW can access all 64 Entries. I think on VLV, we need to update
the fifo_count before waiting for the FIFO."
v2: Apply mask when we read the number of free FIFO entries (Ville).
v3: Mask applied after reading the register (Deepak).
Signed-off-by: Deepak S <deepak.s@intel.com>
[danvet: Add further explanation from Deepak to commit message.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter
is hooked up to pipe B, so we want to prefer pipe B + plane A.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add the code comment Chris requested in his review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Initialize the FBC vfuncs on gen2 and gen3 chipsets. Also make
a clean split for gen7+ vs. gen5+ vfunc initialization.
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>
On gen2 and gen3 chipsets FBC is supported only on plane A. Fix (and
simplify) the plane checks in intel_update_fbc() accordingly.
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>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilons <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a REG_WRITE_FOOTER macro as a counterpart to the REG_WRITE_HEADER.
The current code has the spin_lock() in the HEADER, but the
spin_unlock() is open coded, which looks rather confusing on the first
glance. A bit of additional symmetry might help.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When inspecting reports that boot/suspend/resume times are unusual it
would be useful to clearly identify the time we must spend waiting for
the hardware to complete its task. In this case we have a notification
before we start waiting for the panel to change state, but none
afterwards - which would be useful.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Checkpatch tells me
WARNING: __packed is preferred over __attribute__((packed))
so switch over to __packed across the driver before adding new packed
structs.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Check that the N and P dividers don't cause a divide by zero.
This shouldn't happen under normal circumstances, but can
happen eg. under simulation.
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>
It's a pain for two reasons:
- The vga plane redisablign requires actual legacy vgao i/o to pull
of. The hw engineers really botched this one here :(
- There seem to be some BIOS out there which send out lid events when
unplugging. Together with our broken DP code, which disables the
port when the cable is lost, this results in an immediate modeset
call, which can hang on the wait for outstanding flips.
- Also we don't want to force a modeset on machines where it's not
really needed, see the referenced bug.
We might want to extend this in general to also all machines that
support opregion, since there the BIOS supposedly should manage the
gfx hardware more cooperatively.
v2: Pimp commit message a bit.
Cc: Roland Dreier <roland@kernel.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=65486
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We're currently misprinting the port name when vlv_wait_port_ready()
times out. Fix it by using port_name().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We had some mode_valid() vfuncs returning an int, others the enum. Let's
use the latter everywhere.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we call intel_display_power_enabled() from
i915_capture_error_state() in IRQ context and then take a mutex. To fix
this add a new intel_display_power_enabled_sw() which returns the domain
state based on software tracking as opposed to reading the actual HW
state.
Since we use domain_use_count for this without locking on the reader
side make sure we increase the counter only after enabling all required
power wells and decrease it before disabling any of these power wells.
Regression introduced in
commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Sep 24 16:17:09 2013 +0300
drm/i915: support for multiple power wells
Note that atm we depend on the value returned by
intel_display_power_enabled_sw() in i915_capture_error_state() to avoid
unclaimed register access reports. This was never guaranteed though,
since another thread can disable the power concurrently. If this is a
problem we need another explicit way to disable the reporting during
error captures.
v2:
- remove barriers as the caller can't depend on the value
returned from i915_capture_error_state_sw() anyway (Ville)
- dump the state of pipe/transcoder power domain state (Daniel)
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
