| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Broadwell hardware supports both ring buffer mode and execlist mode.
When i915 runs inside a VM with Intel GVT-g, we allow execlist mode
only.
The main reason of EXECLIST only is that GVT-g does not support the
dynamic mode switch between ring buffer mode and execlist mode when
running multiple virtual machines.
v2:
- Adjust the position of vgpu check in sanitize function (Joonas)
- Add vgpu error check in context initialization. (Joonas, Daniel)
Signed-off-by: Zhiyuan Lv <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This is based on Mika Kuoppala's patch below:
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/61104/match=workaround+hw+preload
The patch will preallocate the page directories for 32-bit PPGTT when
i915 runs inside a virtual machine with Intel GVT-g. With this change,
the root pointers in EXECLIST context will always keep the same.
The change is needed for vGPU because Intel GVT-g will do page table
shadowing, and needs to track all the page table changes from guest
i915 driver. However, if guest PPGTT is modified through GPU commands
like LRI, it is not possible to trap the operations in the right time,
so it will be hard to make shadow PPGTT to work correctly.
Shadow PPGTT could be much simpler with this change. Meanwhile
hypervisor could simply prohibit any attempt of PPGTT modification
through GPU command for security.
The function gen8_preallocate_top_level_pdps() in the patch is from
Mika, with only one change to set "used_pdpes" to avoid duplicated
allocation later.
Cc: Mika Kuoppala <[email protected]>
Cc: Dave Gordon <[email protected]>
Cc: Michel Thierry <[email protected]>
Signed-off-by: Zhiyuan Lv <[email protected]>
Signed-off-by: Zhi Wang <[email protected]>
Reviewed-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Add a common function to return "yes" or "no" string based on the
argument, and drop the local versions of it.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Make it available outside of intel_dp.c.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Clint Taylor <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
If rc6 is enabled, notify GuC so it can do proper forcewake before
command submission.
Signed-off-by: Alex Dai <[email protected]>
Reviewed-by: Tom O'Rourke <Tom.O'[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The firmware layout changes that now it only has css header +
uCode + RSA signature. Plus, other trivial changes to support
GuC V4.3.
Signed-off-by: Alex Dai <[email protected]>
Reviewed-by: Dave Gordon <[email protected]>
Reviewed-by: Dave Gordon <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The driver doesn't support UMS any more, so set DRIVER_MODESET by default,
remove the legacy s/r callbacks, and rename the s/r functions to make it more clear
they're only in use by switcheroo now.
Also remove an obsolete comment about atomic. Normal updates are supported only
async updates aren't yet.
v2: Don't unconditionally set DRIVER_ATOMIC, we're not yet there.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Make the code mode readable by pulling the "does this crtc have any
encoders?" deduction into a separate function.
Cc: Maarten Lankhorst <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The BIOS sometimes likes to enable pipes w/o any ports, at least on
older machines. Currently we fail to assign anything sensible to
crtc->hwmode.crtc_clock which leads to complaints from the vblank code.
Deal with active pipes w/o ports and assign something sensible to
crtc_clock in i9xx_get_pipe_config(). The encoder .get_config() will
override this if the port is enabled.
Gets rid of rest of these on my gen4:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 24: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 1 is disabled
v2: Fill out crtc_clock already in i9xx_get_pipe_config() (Maarten)
Cc: Maarten Lankhorst <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
At various points when changing the DPIO lane/phy power states,
construct an expected value of the DISPLAY_PHY_STATUS register
and compare it with the real thing.
To construct the expected value we look at our shadow PHY_CONTROL
register value (which should match what we've just written to the
hardware), and we also need to look at the actual state of the cmn
power wells as a disabled power well causes the relevant LDO status
to be reported as 'on' in DISPLAY_PHY_STATUS.
When initially powering up the PHY it performs various internal
calibrations for which it fully powers up. That means that if we check
for the expetected power state immediately upon releasing cmnreset we
would get the occasional false positive. But we can of course
poll until the expected value appears. It shouldn't be too long so
this shouldn't make modesets substantially longer.
One extra complication is introduced when we cross the streams, ie.
drive port B with pipe B. In this case we trick CL2 (where the DPLL lives)
into life by temporaily powering up the lanes in the second channel,
and once the pipe is up and runnign we release the lane power override.
At that point the power state of CL2 has somehow gotten entangled with
the power state of the first channel. That means that constructing the
expected DISPLAY_PHY_STATUS value is a bit tricky since based on the
lane power states in the second channel, CL2 should also be powered
down. But we can use the DPLL enable bit to determine when CL2 should
be alive even if the lanes are powered down. However the power state
of CL2 isn't actually tied in with the DPLL state, but to the state
of the lanes in first channel, so we have to avoid checking the
expected state between shutting down the DPLL and powering down
the lanes in the first channel. So no calling assert_chv_phy_status()
before the DISPLAY_PHY_CONTROL write in chv_phy_powergate_lanes(),
but after the write is a safe time to check.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Add some checks that the state of the DPIO lanes is more or less what we
expect based on the overrides.
The hardware only provides two bits per channel indicating whether all
or some of the lanes are powered down, so we can't do an exact check.
Additionally, CL2 powering down before we can check it adds another
twist. To work around this we simply check for the 0 value of the
CL2 register (which is what we get when it's powered down) and
adjust our expectations.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Currently we release the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.
The one confusing thing in this is that when we remove the power down
override from the lanes, they power up with defaul register values,
which do not have the soft reset overrides enabled. And according to
some docs by default the data lane resets are tied to cmnreset. So that
would mean that lanes would come out of reset without staggering as
soon as the power down overrides are removed. But since we can't access
either the lane stagger register nor the soft reset override registers
until the lanes are powered on, we can't really do anything about it.
So let's just set the soft reset overrides as soon as the lane is
powered on and hope for the best.
v2: Fix typos in commit message (Daniel)
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The DP MST encoder config function never sets ddi_pll_sel, even though
its value is programmed in its ->pre_enable() hook. That used to work
because a new pipe_config was kzalloc'ed at every modeset, and the value
of zero selects the highest clock for the PLL. Starting with the commit
below, the value of ddi_pll_sel is preserved through modesets, and since
the correct value wasn't properly setup by the MST code, it could lead
to warnings and blank screens.
commit 8504c74c7ae48b4b8ed1f1c0acf67482a7f45c93
Author: Ander Conselvan de Oliveira <[email protected]>
Date: Fri May 15 11:51:50 2015 +0300
drm/i915: Preserve ddi_pll_sel when allocating new pipe_config
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91628
Cc: [email protected] # 7e6313a2516d drm/i915: Don't use link_bw for PLL setup
Cc: [email protected]
Cc: Timo Aaltonen <[email protected]>
Cc: Luciano Coelho <[email protected]>
Signed-off-by: Ander Conselvan de Oliveira <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
This was forgotten in
commit d351f6d94893f3ba98b1b20c5ef44c35fc1da124
Author: Francisco Jerez <[email protected]>
Date: Fri May 29 16:44:15 2015 +0300
drm/i915: Add SCRATCH1 and ROW_CHICKEN3 to the register whitelist.
Signed-off-by: Francisco Jerez <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
No functional changes.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
[danvet: s/intel_dp_tps/drm_dp_tps/.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Use port_clock instead of link_bw when picking the PLL parameters for
DP. link_bw may be zero with an eDP 1.4 sink that supports
DP_LINK_RATE_SET so we shouldn't use it for anything other than feed it
to the sink appropriately.
v2: Fix typo in commit message (Sivakumar)
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
[Jani: cherry-picked from future.]
Signed-off-by: Jani Nikula <[email protected]>
|
|
Cc: Thierry Reding <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Commit 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
added code to intel_modeset_gem_init to override the SSC status read
from VBT with the SSC status set by BIOS.
However, intel_modeset_gem_init is invoked *after* intel_modeset_init,
which calls intel_setup_outputs, which *modifies* SSC status by way of
intel_init_pch_refclk. So unlike advertised, intel_modeset_gem_init
doesn't preserve the SSC status set by BIOS but whatever
intel_init_pch_refclk decided on.
This is a problem on dual gpu laptops such as the MacBook Pro which
require either a handler to switch DDC lines, or the discrete gpu
to proxy DDC/AUX communication: Both the handler and the discrete
gpu may initialize after the i915 driver, and consequently, an LVDS
connector may initially seem disconnected and the SSC therefore
is disabled by intel_init_pch_refclk, but on reprobe the connector
may turn out to be connected and the SSC must then be enabled.
Due to 92122789b2d6 however, the SSC is not enabled on reprobe since
it is assumed BIOS disabled it while in fact it was disabled by
intel_init_pch_refclk.
Also, because the SSC status is preserved so late, the preserved value
only ever gets used on resume but not on panel initialization:
intel_modeset_init calls intel_init_display which indirectly calls
intel_panel_use_ssc via multiple subroutines, *before* the BIOS value
overrides the VBT value in intel_modeset_gem_init (intel_panel_use_ssc
is the sole user of dev_priv->vbt.lvds_use_ssc).
Fix this by moving the code introduced by 92122789b2d6 from
intel_modeset_gem_init to intel_modeset_init before the invocation
of intel_setup_outputs and intel_init_display.
Add a DRM_DEBUG_KMS as suggested way back by Jani:
http://lists.freedesktop.org/archives/intel-gfx/2014-June/046666.html
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Paul Hordiienko <[email protected]>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <[email protected]>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <[email protected]>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <[email protected]>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina -- work in progress]
Fixes: 92122789b2d6 ("drm/i915: preserve SSC if previously set v3")
Signed-off-by: Lukas Wunner <[email protected]>
Reviewed-by: Jesse Barnes <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.
In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.
Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.
This patch also fix the DDI-E hotplug function.
Signed-off-by: Xiong Zhang <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
Enable eDP on DDI-E.
Also let's remove duplicated definitions to avoid later confusion.
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Xiong Zhang <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
There are OEMs using DDI-E out there,
so let's enable it.
Unfortunately there is no detection bit for DDI-E
So we need to rely on VBT for that.
I also need to give credits to Xiong since before seing
his approach to check info->support_* I was creating an ugly
vbt->ddie_sfuse_strap in order to propagate the ddi presence info
v2: Rebased as last patch in the series. since all other patches
in this series are needed for anything working propperly on DDI-E.
Credits-to: "Zhang, Xiong Y" <[email protected]>
Cc: "Zhang, Xiong Y" <[email protected]>
Reviewed-by: Xiong Zhang <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
v3: MISSING_CASE take place of BUG()
Signed-off-by: Xiong Zhang <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
Author: Imre Deak <[email protected]>
Date: Thu Oct 23 19:23:26 2014 +0300
drm/i915: add poweroff_late handler
introduced a regression on old platforms during hibernation. A workaround was
added in
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb
Author: Imre Deak <[email protected]>
Date: Mon Mar 2 13:04:41 2015 +0200
drm/i915: gen4: work around hang during hibernation
using an explicit blacklist for the GENs/BIOS vendors where the issue was
reported. Later there we had reports of the same failure on platforms not on
this list.
To my best knowledge the correct thing to do is still to put the device to PCI
D3 state during hibernation, see [1] and [2] for the reasons. This also aligns
with our future plans to unify more the runtime and system suspend/resume
paths. Since an exact blacklist seems to be impractical (multiple GENs and
BIOS vendors are affected) apply the workaround on everything pre GEN6.
[1] http://lists.freedesktop.org/archives/intel-gfx/2015-February/060710.html
[2] https://lkml.org/lkml/2015/6/22/274
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=95061
Reported-by: Ilya Tumaykin <[email protected]>
Reported-by: Dirk Griesbach <[email protected]>
Reported-by: Pavel Machek <[email protected]>
Reported-by: Mikko Rapeli <[email protected]>
Tested-by: Mikko Rapeli <[email protected]>
Reported-by: Paul Bolle <[email protected]>
CC: [email protected]
Signed-off-by: Imre Deak <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.
If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.
Also remove the leftover comment that referred to the old retraining
from .hot_plug().
Fixes a regression introduced in:
commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
Author: Dave Airlie <[email protected]>
Date: Fri May 2 14:02:48 2014 +1000
drm/i915: add DP 1.2 MST support (v0.7)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Tested-by: Palmer Dabbelt <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
Since BIOS RC 1.4 it would enable CDCLK PLL during BIOS S3 resume, then
driver needs to set CDCLK to avoid display corruption if DPLL0 enabled.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91697
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Damien Lespiau <[email protected]>
Reviewed-by: Cooper Chiou <[email protected]>
Reviewed-by: Wei Shun Chang <[email protected]>
Tested-by: Gary Wang <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Gavin Hindman <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Xiong Y Zhang <[email protected]>
Signed-off-by: Gary Wang <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
|
|
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This partially reverts commit 74c090b1bdc57b1c9f1361908cca5a3d8a80fb08.
The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
support.
Signed-off-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Dear git bisect user,
Even though this is the patch that introduced the WARN() you're
bisecting, please notice that it's very likely that the problem you're
facing was already present before this commit. In other words: this
commit adds code to detect errors and give WARN()s about them, but the
errors were already there.
In order to continue your debug, please use the i915.mmio_debug
option, check the backtraces and try to discover which read or write
operation is causing the error message. Then check if this is
happening because the register does not exist or because its power
well is down when the operation is being done.
On my SKL machine, if I use i915.mmio_debug=999, this patch triggers
42 WARNs just by booting. I didn't investigate them yet. Normal users
are only going to get a single WARN due to the default i915.mmio_debug
setting.
Thank you for your comprehension,
Paulo
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We can choose to leave the display PHY CL2 powerdown up to some hardware
signals, or we can force it. The BXT code forces the nonexistent CL2 in
the x1 PHY to power down. Follow suit on CHV. Maybe it can still save
some extra power by disabling some extra logic in CL1, or something.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
CHV has supports some form of automagic clock gating for the
DPIO SUS clock. We can simply enable the magic bits and the
hardware should take care of the rest.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
With DPIO powergating active the DPLL can't be accessed unless
something else is keeping the common lane in the channel on.
That means the PPS kick procedure could fail to enable the PLL.
Power up some data lanes to force the common lane to power up
so that the PLL can be enabled temporarily.
v2: Avoid gcc uninitilized variable warning
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Normmally the common lane in a PHY channel gets powered up when some
of the data lanes get powered up. But when we're driving port B with
pipe B we don't want to enabled any of the data lanes, and just want
the DPLL in the common lane to be active.
To make that happens we have to temporarily enable some data lanes
after which we can access the DPLL registers in the common lane. Once
the pipe is up and running we can drop the power override on the data
lanes allowing them to shut down. From this point forward the common
lane will in fact stay powered on until the data lanes in the other
channel get powered down.
Ville's extended explanation from the review thread:
On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
> One Q, why only for port B? Port C is also in same common lane right?
Port B is in the first PHY channel which also houses CL1. CL1 always
powers up whenever any lanes in either PHY channel are powered up.
CL2 only powers up if lanes in the second channel (ie. the one with
port C) powers up.
So in this scenario (pipe B->port B) we want the DPLL from CL2, but
ideally we only want to power up the lanes for port B. Powering up
port B lanes will only power up CL1, but as we need CL2 instead we
need to, temporarily, power up some lanes in port C as well.
Crossing the streams the other way (pipe A->port C) is not a problem
since CL1 powers up whenever anything else powers up. So powering up
some port C lanes is enough on its own to make the CL1 DPLL
operational, even though CL1 and the lanes live in separate channels.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
[danvet: Amend commit message with extended explanation.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Powergate the PHY lanes when they're not needed. For HDMI all four lanes
are needed always, but for DP we can enable only the needed lanes. To
power down the unused lanes we use some power down override bits in the
DISPLAY_PHY_CONTROL register. Without the overrides it appears that the
hardware always powers on all the lanes. When the port is disabled the
power down override is not needed and the lanes will shut off on their
own. That also means the override is critical to actually be able to
access the DPIO registers before the port is actually enabled.
Additionally the common lanes will power down when not needed. CL1
remains on as long as anything else is on, CL2 will shut down when
all the lanes in the same channel will shut down. There is one exception
for CL2 that will be dealt in a separate patch for clarity.
With potentially some lanes powered down, the DP code now has to check
the number of active lanes before accessing PCS/TX registers. All
registers in powered down blocks will reads as 0xffffffff, and soe we
would drown in warnings from vlv_dpio_read() if we allowed the code
to access all those registers.
Another important detail in the DP code is the "TX latency optimal"
setting. Normally the second TX lane acts as some kind of reset master,
with the other lanes as slaves. But when only a single lane is enabled,
that single lane obviously has to be the master.
A bit of extra care is needed to reconstruct the initial state of the
DISPLAY_PHY_CONTROL register since it can't be read safely. So instead
read the actual lane status from the DPLL/PHY_STATUS registers and
use that to determine which lanes ought to be powergated initially.
We also need to switch the PHY power modes to "deep PSR" to avoid
a hard system hang when powering down the single channel PHY.
Also sprinkle a few debug prints around so that we can monitor the
DISPLAY_PHY_STATUS changes without having to read it and risk
corrupting it.
v2: Add locking to chv_powergate_phy_lanes()
v3: Actually enable dynamic powerdown in the PHY and deal with the
fallout
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Bunch of stuff needs the DPLL ref/cri clocks on both VLV and CHV,
and having VGA mode enabled causes some problems for CHV. So let's just
pull the code to configure those bits into the disp2d well enable hook.
With the DPLL disable code also fixed to leave those bits alone we
should now have a consistent DPLL state all the time even if the DPLL
is disabled.
This also neatly removes some duplicated code between the VLV and
CHV codepaths.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Most of our char* arrays are markes as const already, but a few slipped
through the cracks. Fix it.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
A couple of hand rolled ARRAY_SIZE()s caught my eye. Get rid of them.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Simple one:
drivers/gpu/drm/i915/i915_debugfs.c:2449:57: warning: Using plain integer as NULL pointer
And something a bit more peculiar:
drivers/gpu/drm/i915/i915_debugfs.c:4953:18: warning: Variable length array is used.
drivers/gpu/drm/i915/i915_debugfs.c:4953:32: warning: Variable length array is used.
We pass a 'const int' as the array size which results in the warning,
dropping the const gets rid of the warning. Weird, but I think getting
rid of the warnings is better than holding on to the const.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
BXT platform uses live status bits from 0x44440 register to obtain DP
status on hotplug. The existing g4x_digital_port_connected() uses a
different register and hence misses DP hotplug events on BXT
platform. This patch fixes it by using the appropriate register(0x44440)
and live status bits(3:5).
Based on a patch by Durgadoss R <[email protected]>, from whom the
commit message is shamelessly copy pasted.
Reported-by: Durgadoss R <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Choose the right function at the intel_digital_port_connected level.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.
v2: make the function return a boolean
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
With the case added for eDP on port A (always connected from this
function's point of view), we should not be hitting any of the default
cases in ibx_digital_port_connected, so add MISSING_CASE annotation.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We should not be hitting any of the default cases in
g4x_digital_port_connected, so add MISSING_CASE annotation and return
boolean status. The current behaviour is just cargo culting from the
days of yonder when the display port support was added to i915.
Signed-off-by: Jani Nikula <[email protected]>
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The function can be made static there. No functional changes.
Reviewed-by: Durgadoss R <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DVO.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- clock check against max dotclock moved inside 'if (fixed_mode)'
V5:
- dot clock check against fixed_mode clock when available
Signed-off-by: Mika Kahola <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to DSI.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- max_pixclk variable renamed as max_dotclk
- moved dot clock checking inside 'if (fixed_mode)'
V5:
- dot clock checked against fixed_mode clock
Signed-off-by: Mika Kahola <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.
This patch applies to LVDS.
V2:
- removed computation for max pixel clock
V3:
- cleanup by removing unnecessary lines
V4:
- moved supported dotclock check from mode_valid() to intel_lvds_init()
V5:
- dotclock check moved back to mode_valid() function
- dotclock check for fixed mode
Signed-off-by: Mika Kahola <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
V2:
- limit the max dot clock frequency to max CD clock frequency
for the gen9 and above
- limit the max dot clock frequency to 90% of the max CD clock
frequency for the older gens
- for Cherryview the max dot clock frequency is limited to 95%
of the max CD clock frequency
- for gen2 and gen3 the max dot clock limit is set to 90% of the
2X max CD clock frequency
V3:
- max_dotclk variable renamed as max_dotclk_freq in i915_drv.h
- in intel_compute_max_dotclk() the rounding method changed from
round up to round down when computing max dotclock
V4:
- Haswell and Broadwell supports now dot clocks up to max CD clock
frequency
Signed-off-by: Mika Kahola <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Add vlv_dport_to_phy() and fix up the return values of
vlv_dport_to_channel() and vlv_pipe_to_channel() to use
the appropriate enums.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
With DPIO powergating active on CHV, we can't even access the DPIO PLL
registers until the lane power state overrides have been enabled. That
will happen from the encoder .pre_pll_enable() hook, so move
chv_prepare_pll() to happen after that point, which puts it just before
chv_enable_pll() actually.
Do the same for VLV to avoid accumulating weird differences between the
platforms. Both platforms seem happy with the new arrangement.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Deepak S <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|