For the device to enter D3 we should enable PCH clock gating.
v2:
- use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo)
- rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo)
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>
We did not mention the workaround name when implementing those. This
should help us track what we already implement.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already have the same check on intel_enable_ddi. This patch
prevents "unclaimed register" messages when the power well is
disabled.
V2: Reset intel_crtc->eld_vld to false after the mode_set function.
V3: Add both "type != INTEL_OUTPUT_EDP" requested.
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>
In the error state function we read the registers without checking if
the power well is on, so after doing this we have to clear the
FPGA_DBG_RM_NOCLAIM bit to prevent the next I915_WRITE from detecting
it and printing an error message.
The first version of this patch was checking for the power well state
and then avoiding reading registers that were off, but the reviewers
requested to just read the registers any way and then later clear the
FPGA_DBG_RM_NOCLAIM bit.
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>
We need to dump these registers if we want to properly interpret the
others.
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>
This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also allows us to easily
add new domains in case we need.
v2: Add more domains to enum intel_display_power_domain
v3: Even more domains requested
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Supposedly we should use the DAC divider for <300MHz pixel clocks, but as
that doesn't actually work as well as the high freq divider here in
practice, just use the high freq divider all the time.
v2: remove unconditional write (Jesse)
check for pixel rate properly (Jesse)
v3: give up, the DAC divider apparently doesn't work, and low res modes
work ok (Jesse)
remove debug msg (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This regression was introduced in:
commit b074cec8c6
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Apr 25 12:55:02 2013 -0700
drm/i915: move PCH pfit controls into pipe_config
In refactoring this, it was only applied to eDP, which is incorrect. In
fact, if we ever use the panel fitter to deal with overscan on HDMI,
we'll need to extend it again, so just drop the conditional altogether.
v2: drop check for eDP since we can use the fitter in any config (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only one caller. Also drop the intel_ prefix as is now customary for
platform specific and static functions.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- PCH_ prefix for pch registers on ibx/cpt/ppt.
- Drop the DP_ from the link defines, redundant.
- Drop the GMCH from the data defines and instead give the special g4x
registers a consistent _G4X postfix.
v2:
- Realign #defines and use tabs (Paulo).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is possible thanks to moving the m/n stuff into pipe_config.
Unfortunately we need to move them a bit to avoid forward
declarations.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While at it, also extract a common helper to copy the timings from the
cpu transcoder to the pch transcoder. That way it's really explicit
how the lpt transcoder is hardcoded.
v2:
- Re-align #defines properly (Paulo).
- Use cpu_transcoder when copying pipe timings (Paulo).
- s/intel_pch_transcoder_enable/intel_pch_transcoder_set_timings/
since we already have a pch transcoder enable function, and this is
clearer, too.
- Fixup 80 char line overflow in intel_display.c. I've opted to ignore
this in i915_reg.h and i915_ums.c since meh.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Every time I read hsw code I get completely confused about this. So
call it what it is more explicitly.
Also, add an LPT_TRANSCONF for the pch transcoder A and use it in
lpt-only code, to really unconfuse me.
v2: s/plane/pipe/ in the TRANSCONF #define (Paulo).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the hw state readout&check code it's important that the values we
keep around are the canonical ones. Unfortunately when adding the pipe
timings readout support I've missed that the write side adjusts the
timings in the pipe config.
Fix this up and so prevent the unsightly WARN noise in dmesg. This
regression has been introduced in
commit 1bd1bd8060
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Apr 29 21:56:12 2013 +0200
drm/i915: hw state readout support for pipe timings
Reported-by: Paulo Zanoni <przanoni@gmail.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can't read the pfit regs if the power well is off, so use the cached
value.
v2: re-add lost comment (Jesse)
make sure the crtc using the fitter is actually enabled (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop now unused dev_priv, as spotted by Mika.]
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Writing hw registers from compute_config?
Just say no!
In this case not too horrible since we write a constant 0, and only
debugging would put something else in there. But while checking that
code I've noticed that this register disappeared on pch platforms, so
fix that up, too.
And adjust the comment a bit, it's outdated.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.
Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure if we really need it) compute the modeline from that.
v2: Also read out the pipe source dimensions into the requested mode.
v3: Rebase on top of the moved cpu_transcoder.
v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also
properly #undef that macro again.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
[danvet: Use the existing mask for interlaced bits, spotted by Mika.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to use the fdi m/n values to easily compute the adjusted mode
dotclock on pch ports. Hence make sure the values stored in the pipe
config are always reliable.
v2: Fixup FDI TU readout.
v3: Rebase on top of moved cpu_transcoder.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This code will get _really_ repetive, and we'll end up with tons more
of this kind. So extract the common patterns.
This should also help when we add a lazy pipe_config compare mode for
fastboot.
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.
So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.
LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).
eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
don't match vbt. So failing the modeset is the right thing to do.
But since that also means it's the only way to light up the panel,
it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
need additional tricks. Before that happens it's imo no use trying
to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.
v2: Rebased on top of a bikeshed from Paulo.
v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!
v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.
v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in intel_crt_mode_valid. Unfortunately LPT does not
support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze
in a few more modes.
v2: Rebased on top of Ben Widawsky's num_pipes reorg.
v3: Rebase on top of Ville's pipe debug output ocd rampage.
v4: Fixup rebase fail spotted by Ville.
v5: Fixup rebase fail spotted by Imre Deak. I suck.
Cc: Imre Deak <imre.deak@intel.com>
Cc: 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>
Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Introduce some nice #defines for the FDI lane width fields and put
them to good use. Suggested by Ville.
v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and
use the shift #define also in the mask.
Cc: Imre Deak <imre.deak@intel.com>
Cc: 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>
We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
dithering down a bit.
Just search&replace in this patch, no functional change at all.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.
Note that compared to pch based platforms g4x/vlv don't support 12bpc
modes. g4x is already caught, extend the check for vlv.
The other fixup is to restrict the lvds-specific dithering to early
gen4 devices - g4x should use the pipeconf dither controls. Note that
on gen2/3 the dither control is in the panel fitter even.
v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting
from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4":
"Programming note: Dithering should only be enabled for 8 bpc or 6
bpc."
v3: Actually drop the old ugly dither code.
v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp
pipes (Jesse).
v5: Also clear the dither type correctly as spotted by Ville.
v6: As Ville pointed out we need to indeed set the dithering both in
the pipeconf register (for DP outputs) and in the LVDS port register
(for LVDS ouputs). Otherwise LVDS panel will not get properly
dithered. The old patch got away with this since it forgot to clear
the LVDS dither bit ...
v7: Remove redundant BPC_MASK clearing, spotted by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They can get at the adjusted mode through intel_crtc->config.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This hack is getting a bit messy, but this plugs the leak for now
until we have the cpu_transcoder properly pipe_config'ed.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And put the pfit stuff into substructs while we're at it.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This gets the panel fitter working on eDP on VLV, and should also apply
to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one
panel as eDP anyway).
A few cleanups are still possible on top of this, for example the LVDS
border control could be placed in the LVDS encoder structure and updated
based on the result of the panel fitter calculation.
Multi-pipe fitting isn't handled correctly either if we ever get a config
that wants to try the panel fitter on more than one output at a time.
v2: use pipe_config for storing pfit values (Daniel)
add i9xx_pfit_enable function for use by 9xx and VLV (Daniel)
v3: fixup conflicts and lvds_dither check
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: fix up botched conflict resolution from Jesse:
- border = LVDS_BORDER_ENABLE was lost for CENTER scaling
- comment about gen2/3 panel fitter scaling was lost
- dev_priv->lvds_dither reintroduced.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We only ever check whether it's strictly bigger than one, so all the
is_sdvo/is_hdmi checks are redundant. Flatten the code a bit.
Also, s/temp/dpll_md/
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If we compute the pch pll state, we _have_ a pch encoder.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
g4x dplls and ilk+ pch plls have a separate field for the reduced p1
setting, so this restriction does not apply. Only older platforms have
the restriction that the p1 divisors must match.
This unnecessary restriction has been introduced in
commit cec2f356d5
Author: Sean Paul <seanpaul@chromium.org>
Date: Tue Jan 10 15:09:36 2012 -0800
drm/i915: Only look for matching clocks for LVDS downcloc
Note that with lvds the p2 divisors _always_ match for LVDS, and we
don't support auto-downclocking anywhere else. On eDP downclocking
works with separate data m/n settings, using the same link clock.
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Up to now we've relied on the bios to get this right for us. Let's try
out whether our code has improved a bit, since we should dither
always when the output bpp doesn't match the plane bpp.
- gen5+ should be fine, since we only use the bios hint as an upgrade.
- gen4 changes, since here dithering is still controlled in the lvds
register.
- gen2/3 has implicit dithering depeding upon whether you use 2 or 3
lvds pairs (which makes sense, since it only supports 8bpc pipe
outpu configurations).
- hsw doesn't support lvds.
v2: Remove redudant dither setting.
v3: Completly drop reliance on dev_priv->lvds_dither.
v4: Enable dithering on gen2/3 only when we have a 18bpp panel, since
up-dithering to a 24bpp panel is not supported by the hw. Spotted by
Ville.
v5: Also only enable lvds port dithering on gen4 for 18bpp modes. In
practice this only excludes dithering a 10bpc plane down for a 24bpp
lvds panel. Not something we truly care about. Again noticed by Ville.
v6: Actually git add.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the exception of hsw, which has dedicated DP clocks which run at
the fixed frequency already, and vlv, which doesn't have optmized
pre-defined dp clock parameters (yet).
v2: Ville asked me to elaborate a bit more on the longer-term goals
wrt dpll settings computation:
So ultimately my idea is that in the compute config stage first the crtc
code puts the default platform pll limits into the pipe_config. Then
encoders can either overwrite that limit structure with their own special
stuff (mostly for lvds madness). Or they can pick some or all of the
parameters (e.g. just the p2 switchover on hdmi, or all the clock
parameters for dp/sdvo tv).
Once that's done then the generic crtc code can fill out any missing bits
(using the find_best_pll code) and then try to assign which pll to use (if
it's a platform with shared plls). In the end the modeset could should
simply write the computed stuff into registers and never be able to fail.
Of course there's still a lot of data to be moved into pipe_config to make
this all happen, hence some of the temporary ugliness.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was somehow lost in the pipe_config->dpll introduction in
commit f47709a950
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 28 10:42:02 2013 +0100
drm/i915: create pipe_config->dpll for clock state
While at it, extract a few small helpers for common computations.
v2: Use the newly added helpers more thanks to Ville's trick to
typedef the legacy intel_clock_t as the new-world struct dpll.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need the dpll/fp/fp2 values only when we need a pch pll. So move
them together with the code to acquire such a pll.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Prevents black screens when using 30bpp framebuffers on my
HDMI screens here. The DP input on the same screen though reports a
1.4 EDID with the correct 8bpc limit set.
v2: Actually check for the right thing!
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our rps code relies on the interrupts being off to prevent re-arming
of the work items at inopportune moments.
Also drop the redundant cancel_work for the main rps work,
disable_gt_powersave already takes care of that.
Finally add a WARN_ON to ensure we obey that piece of ordering
constraint. Long term I want to lock down the setup/teardown code in a
similar way to how we painstakingly check modeset sequence constraints
already.
v2: Disable polling after hpd handling is shut down - since Egbert's
hpd irq storm handling the hotplug work can re-arm the polling
handler. Spotted by Jani Nikula.
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The BIOS uses power of two values for the data/link N value.
Follow suit to make the Zotac DP to dual-HDMI dongle work.
v2: Clean up the magic numbers and defines
Change the N clamping to be a bit easier on the eye
Rename intel_reduce_ratio to intel_reduce_m_n_ratio
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59810
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This allows unifying a bunch of the PLL calculations and whatnot.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... inside haswell_get_pipe_config. Because there's one TRANS_DDI_FUNC_CTL
register per CPU transcoder, not per pipe. This solves "unclaimed register"
messages when booting with eDP only and using the i915.disable_power_well=1.
Also fix a comment and remove an useless empty line.
The error messages were caused by:
commit 88adfff1ad
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 28 10:42:01 2013 +0100
drm/i915: hw readout support for ->has_pch_encoders
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>
This fixes "unclaimed register" messages when booting with eDP only
and i915.disable_power_well=1.
The error messages were caused by:
commit 0e8ffe1bf8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 28 10:42:00 2013 +0100
drm/i915: add hw state readout/checking for pipe_config
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>
In this commit we enable both CPU and PCH FIFO underrun reporting and
start reporting them. We follow a few rules:
- after we receive one of these errors, we mask the interrupt, so
we won't get an "interrupt storm" and we also won't flood dmesg;
- at each mode set we enable the interrupts again, so we'll see each
message at most once per mode set;
- in the specific places where we need to ignore the errors, we
completely mask the interrupts.
The downside of this patch is that since we're completely disabling
(masking) the interrupts instead of just not printing error messages,
we will mask more than just what we want on IVB/HSW CPU interrupts
(due to GEN7_ERR_INT) and on CPT/PPT/LPT PCHs (due to SERR_INT). So
when we decide to mask PCH FIFO underruns for pipe A on CPT, we'll
also be masking PCH FIFO underruns for pipe B, because both are
reported by SERR_INT, which has to be either completely enabled or
completely disabled (in othe words, there's no way to disable/enable
specific bits of GEN7_ERR_INT and SERR_INT).
V2: Rename some functions and variables, downgrade messages to
DRM_DEBUG_DRIVER and rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In Valleyview voltage swing, pre-emphasis and lane control registers can
be programmed only through the h/w side band fabric. Update
vlv_update_pll, i9xx_crtc_enable, and intel_enable_pll with the
appropriate programming.
We need to make sure that the tx lane reset occurs in both the full mode
set and DPMS paths, so factor things out to allow that.
v2: use different DPIO_DIVISOR values for VGA and DisplayPort
v3: Fix update pll logic to use same DPIO_DIVISOR & DPIO_REFSFR values
for all display interfaces
v4: collapse with various updates
v5: squash with crtc enable/pll enable bits
v6: split out DP code (jbarnes)
put phyready check under IS_VALLEYVIEW (jbarnes)
remove unneeded check in 9xx pll div update (Jani)
wrap VLV pll update call in IS_VALLEYVIEW (Jani)
move port enable back to end of crtc enable (jbarnes)
put phyready check under IS_VALLEYVIEW (jbarnes)
v7: fix up conflicts against latest drm-intel-next-queued
v8: use DPIO reg names, fix pipes (Jani)
from mPhy_registers_VLV2_ww20p5 doc
v9: update to latest info from driver enabling notes doc
driver_vbios_notes_9
v10: fixup a bit of pipe/port confusion to allow eDP and HDMI to work
simultaneously (Jesse)
v11: use pll/port callbacks for DPIO port activity (Daniel)
use separate VLV CRTC enable function (Daniel)
move around port ready checks (Jesse)
Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop pfit changes and add a little comment explaining that
vlv has a different enable sequence and so needs it's own crtc_enable
callback. Also apply a fixup patch from Wu Fengguang to shut up some
compiler warnings.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a reset feature we don't actually need.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Make it compile.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Program few Tx buffer Swing control settings through DPIO.
v2: fix up codingstyle (Daniel)
call from set_signal_levels (Ville, Daniel)
use proper port numbers (Jesse)
Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Yogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2 changes)
[danvet: Reorder if-ladder to avoid two IS_VLV checks.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Magic updates.
v2: use 64 bit types and math (Ville)
v3: Trim out all the m/n/p calculation changes since they are still
under discussion. Instead squash in a fixup for hdmi limits which
slipped into a different patch.
Signed-off-by: Pallavi G <pallavi.g@intel.com>
Signed-off-by: Vijay Purushothaman <vijay.a.purushothaman@intel.com>
Signed-off-by: Yogesh M <yogesh.mohan.marimuthu@intel.com>
Signed-off-by: Gajanan Bhat <gajanan.bhat@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add sprite_name() macro which should be used with the kind of sprites
that are fixed to pipes (gen4.5+).
Also use dev_priv->num_plane to calculate the sprite index insted
assuming two sprites per pipe. This should make it print the right
name.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Print the alphabetical name for transcoders. The code already used the
pipe_name() macro for transcoders, so I did the same. But we do have the
(unused) transcoder_name() macro which could be used instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Get rid of the few remaining open coded copies of
pipe_name() and port_name().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When adding the pipe config computation step I've accidentally moved
this a bit away. Which momentarily confused me since the pipe config
step rejected some modesetting operations I expected and so left me
looking in vain for that debug output.
v2: Move the debug output into the right function to prevent this from
happening again.
v3: Make it compile (Ville). Also reorder the patch so that the two
bugfixes are first.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The i9xx modeset sequence is currently pretty fishy, so tight it all
up with some good assert-sprinkling.
We already have good coverage on the disable side, but the enable side
is spotty (since until recently it was wrong).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just blows through 50ms for naught, since the pipe is off.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is horrible lore and we should be able to get rid of it now
that the lvds/pfit handling code actually does the right thing.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oops.
This regression has been introduced in
commit 5d2d38ddca
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 27 00:45:01 2013 +0100
drm/i915: clean up pipe bpp confusion
Reported-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
->disable and other modeset callbacks.
In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.
v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The recent rework of the pfit handling didn't take into account that
the panel fitter is fixed to pipe B:
commit 24a1f16de9
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Fri Feb 8 16:35:37 2013 +0200
drm/i915: disable shared panel fitter for pipe
Fix this up by properly computing the pipe the pfit is on. Also
extract the logic into its own function, add a debug assert to check
that the pipe is off (mostly just documentation) and add some debug
output.
If pipe A was disabled after pipe B was set up, the panel fitter will
be disabled. Now most userspace doesn't do modesets in this order,
which is why I couldn't ever reproduce this and why it took me so long
to figure out.
We really need hw state readout and check support for the pannel
fitter ...
Reported-by: Hans de Bruin <jmdebruin@xmsnet.nl>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Hans de Bruin <jmdebruin@xmsnet.nl>
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/19049
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Yet again our current confusion between doing the modeset globally,
but only having the new parameters for one crtc at a time.
So that intel_set_mode essentially already does a global modeset:
intel_modeset_affected_pipes compares the current state with where we
want to go to (which is carefully set up by intel_crtc_set_config) and
then goes through the modeset sequence for any crtc which needs
updating.
Now the issue is that the actual interface with the remaining code
still only works on one crtc, and so we only pass in one fb and one
mode. In intel_set_mode we also only compute one intel_crtc_config
(which should be the one for the crtc we're doing a modeset on).
The reason for that mismatch is twofold:
- We want to eventually do all modeset as global state changes, so
it's just infrastructure prep.
- But even the old semantics can change more than one crtc when you
e.g. move a connector from crtc A to crtc B, then both crtc A and B
need to be updated. Usually that means one pipe is disabled and the
other enabled. This is also the reason why the hack doesn't touch the
disable_pipes mask.
Now hilarity ensued in our kms config restore paths when we actually
try to do a modeset on all crtcs: If the first crtc should be off and
the second should be on, then the call on the first crtc will notice
that the 2nd one should be switched on and so tries to compute the
pipe_config. But due to a lack of passed-in fb (crtc 1 should be off
after all) it only results in tears.
This case is ridiculously easy to hit on gen2/3 where the lvds output
is restricted to pipe B. Note that before the pipe_config bpp rework
gen2/3 didn't care really about the fb->depth, so this is a regression
brought to light with
commit 4e53c2e010
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 27 00:44:58 2013 +0100
drm/i915: precompute pipe bpp before touching the hw
But apparently Ajax also managed to blow up pch platforms, probably
with some randomized configs, and pch platforms trip up over the lack
of an fb even in the old code. So this actually goes back to the first
introduction of the new modeset restore code in
commit 45e2b5f640
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Nov 23 18:16:34 2012 +0100
drm/i915: force restore on lid open
Fix this mess by now by justing shunting all the cool new global
modeset logic in intel_modeset_affected_pipes.
v2: Improve commit message and clean up all the comments in
intel_modeset_affected_pipes - since the introduction of the modeset
restore code they've been a bit outdated.
Bugzill: https://bugzilla.redhat.com/show_bug.cgi?id=917725
Cc: stable@vger.kernel.org
References: http://www.mail-archive.com/stable@vger.kernel.org/msg38084.html
Tested-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.
A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Peter Verthez <peter.verthez@skynet.be>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This solves some "unclaimed register" messages when booting the
machine with eDP attached.
V2: Rebase and add the comment requested by Daniel.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It returns true if we've requested to turn the power well on and it's
really on. It also returns true for all the previous gens.
For now there's just one caller, but I'm going to add more.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.
Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.
v2: Try harder not to create a big patch (Chris).
v3: Even smaller (still Chris). Also fix a trailing space.
References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin <tomas.melin@iki.fi>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Tomas Melin <tomas.melin@iki.fi>
Tested-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bspec has been been updated and dropped these two changes for non-sdv
LPT PCHs.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Userspace can easily hit this and does since Ville added a new evil
igt testcase in:
commit 069e35e0fc3785faa562adcfd2dd7bbed4cb1dea
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Mar 4 15:34:06 2013 +0200
kms_flip: Add flip-vs-bad-tiling test
v2: Fix the spelling in the added comment (Chris).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63246
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the ratio is different, we also need to pass in the parameters
for the reduced clock. Might or might not reduce flicker for the
auto-downclocking on lvds/eDP.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only on IBX should we set the limiting factor to 25 unconditionally
for dual-channel mode, on CPT/PPT 25 only applies when the lvds
refclock is 100MHz.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit de13a2e3f8
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Sep 20 18:36:05 2012 -0300
drm/i915: extract compute_dpll from ironlake_crtc_mode_set
missed the subtle adjustment of the FP1 register. Fix this up by
passing a pointer around instead of the value.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GEN supports a fusing option which subtracts the PCH display (making the
CPU display also useless). In this configuration MMIO which gets decoded
to a certain range will hang the CPU.
For us, this is sort of the equivalent of having no pipes, and we can
easily modify some code to not do certain things with no pipes.
v2: Moved the num pipes check up in the call chain, and removed extra
checks noted by Daniel. For more details, see:
http://lists.freedesktop.org/archives/intel-gfx/2013-March/025746.html
v3: Drop the intel_setup_overlay check (Daniel)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VLV has the color range selection bit in the PIPECONF register.
Configure it appropriately.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: fixup rebase issues due to slightly different baseline.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Clock computations and handling are highly encoder specific, both in
the optimal clock selection and also in which clocks to use and when
sharing of clocks is possible.
So the best place to do this is somewhere in the encoders, with a
generic fallback for those encoders without special needs. To facility
this, add a pipe_config->clocks_set boolean.
This patch here is only prep work, it simply sets the computed clock
values in pipe_config->dpll, and uses that data in the hw clock
setting functions.
Haswell code isn't touched, simply because Haswell clocks work much
different and need their own infrastructure (with probably a
Haswell-specific config->ddi_clock substruct).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now we can ditch the checks in the Haswell disable code.
v2: add support for Haswell
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to be able to read out the hw state code for a bunch
of reasons:
- Correctly disabling boot-up/resume state.
- Pure paranoia.
Since not all of the pipe configuration is e.g. relevant for
fastboot (or at least we can allow some wiggle room in some
parameters, like the clocks), we need to add a strict_checking
parameter to intel_pipe_config_compare for fastboot.
For now intel_pipe_config_compare should be fully paranoid and
check everything that the hw state readout code supports. Which
for this infrastructure code is nothing.
I've gone a bit overboard with adding 3 get_pipe_config functions:
The ilk version will differ with the next patch, so it's not too
onerous.
v2: Don't check the hw config if the pipe is off, since an enabled,
but dpms off crtc will obviously have tons of difference with the hw
state.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only exception left is is_cpu_edp in the haswell modeset code.
We need that to assign the cpu transcoder, but we might want to
move that eventually into the encoder, too.
\o/-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need it in the fdi m_n computation, which nicely kills almost
all ugly special cases in there.
It looks like we also need this to handle 12bpc hdmi correctly.
Eventually it might be better to switch things around and put the
target clock into adjusted_mode->clock and create a new pipe_config
parameter for the port link clock.
v2: Add a massive comment in the code to explain this mess.
v3: s/dp_target_clock/pixel_target_clock in anticipation of the hdmi
use-case.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need a flag to designate dp encoders and the dp link m_n parameters
in the pipe config for that. And now that the pipe bpp computations
have been moved up and stored in the pipe config, too, we can do this
without losing our sanity.
v2: Rebased on top of Takashi Iwai's fix to (again) fix the target
clock handling for eDP. Luckily the new code is sane enough and just
does the right thing!
v3: Move ->has_dp_encoder to this patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's a rather decent confusion going on around transcoder m_n
values. So let's clarify:
- All dp encoders need this, either on the pch transcoder if it's a
pch port, or on the cpu transcoder/pipe if it's a cpu port.
- fdi links need to have the right m_n values for the fdi link set in
the cpu transcoder.
To handle the pch vs transcoder stuff a bit better, extract transcoder
set_m_n helpers. To make them simpler, set intel_crtc->cpu_transcoder
als in ironlake_crtc_mode_set, so that gen5+ (where the cpu m_n
registers are all at the same offset) can use it.
Haswell modeset is decently confused about dp vs. edp vs. fdi. dp vs.
edp works exactly the same as dp (since there's no pch dp any more),
so use that as a check. And only set up the fdi m_n values if we
really have a pch encoder present (which means we have a VGA encoder).
On ilk+ we've called ironlake_set_m_n both for cpu_edp and for pch
encoders. Now that dp_set_m_n handles all dp links (thanks to the
pch encoder check), we can ditch the cpu_edp stuff from the
fdi_set_m_n function.
Since the dp_m_n values are not readily available, we need to
carefully coax the edp values out of the encoder. Hence we can't (yet)
kill this superflous complexity.
v2: Rebase on top of the ivb fdi B/C check patch - we need to properly
clear intel_crtc->fdi_lane, otherwise those checks will misfire.
v3: Rebased on top of a s/IS_HASWELL/HAS_DDI/ patch from Paulo Zanoni.
v4: Drop the addition of has_dp_encoder, it's in the wrong patch (Jesse).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRWLTrAAoJEHm+PkMAQRiGe8oH/iMy48mecVWvxVZn74Tx3Cef
xmW/PnAIj28EhSPqK49N/Ow6AfQToFKf7AP0ge20KAf5teTq95AY+tH74DAANt8F
BjKXXTZiR5xwBvRkq7CR5wDcCvEcBAAz8fgTEd6SEDB2d2VXFf5eKdKUqt1avTCh
Z6Hup5kuwX+ddtwY2DCBXtp2n6fL0Rm5yLzY1A3OOBye1E7VyLTF7M5BR603Q44P
4kRLxn8+R7jy3hTuZIhAeoS8TKUoBwVk7DmKxEzrhTHZVOmvwE9lEHybRnIyOpd/
k1JnbRbiPsLsCVFOn10SQkGDAIk00lro3tuWP2C1ljERiD/OOh5Ui9nXYAhMkbI=
=q15K
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc5' into drm-intel-next-queued
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups
for -next, but they will conflict all over the place with
commit 9d1a455b0c
Author: Takashi Iwai <tiwai@suse.de>
Date: Mon Mar 18 11:25:36 2013 +0100
drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n()
from -fixes.
Conflicts:
drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed.
drivers/gpu/drm/i915/intel_panel.c: A field rename in -next
conflicts with a bugfix in -fixes. Take the version from
-fixes and apply the rename.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Need to make sure sprites are disabled before shutting off a pipe.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
No constant alpha yet though, that needs a new ioctl and/or property to
get/set.
v2: use drm_plane_format_cpp (Ville)
fix up vlv_disable_plane, remove IVB bits (Ville)
remove error path rework (Ville)
fix component order confusion (Ville)
clean up platform init (Ville)
use compute_offset_xtiled (Ville)
v3: fix up more format confusion (Ville)
update to new page offset function (Ville)
v4: remove incorrect formats from framebuffer_init (Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modifying the clock sources (via the DREF control on the PCH) is a slow
multi-stage process as we need to let the clocks stabilise between each
stage. If we are not actually changing the clock sources, then we can
return early.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch by deleting a space after a ~]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville pointed out that my assumption that no unsupported pixel format
can get past the pipe config computation stage to the platform
update_plane callbacks is wrong. The reason is that this function
still checks the old fb->depth value instead of the new pixel_format.
While checking with all the other places that use this I've noticed
that intel_framebuffer_init already has all the platform checks we
need, so replace those checks with a WARN_ON.
Since fb->depth isn't set for YUV pixel formats and since we already
can't create an fb with an rgb layout not support on the running
platform I /think/ this patch doesn't fix any bug.
But it surely looks better!
v2: BGR formats are also only gen4+, so add the corresponding WARN_ON,
too (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've mostly switched over to the new more flexible schema, but
there's one check left in the modeset code.
Motivated by a question from Ville whether there's really no way an
unsupported pixel_format can escape into our platform update_plane
callbacks.
v2: Ville noticed that the fb->depth check is redudant when we already
check fb->pixel_format.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- gen4 and earlier (save for g4x) only really have a 8bpc pipe, with
the possibility to dither to 6bpc using the panel fitter
- g4x has hdmi, but no 12 bpc pipe ... !? Clamp hdmi accordingly.
- TV/SDVO out are the only connectors available on platforms with
a pipe bpp != 8, add code to force the pipe to 8bpc unconditionally.
<rant>
The dither handling on gmch platforms is one giant disaster. I'm hoping
somewhat that vlv enabling will fix this up, but given that the 6bpc
handling for edp was simply added with another quick hack, I don't have
high hopes ...
</rant>
v2: Neither vlv nor g4x have 12bpc pipes. Still set pipe_bpp to 12*3,
but let the crtc code clamp things down to 10bpc on these platforms.
v3: Fix a bpc vs. bpp mixup in the gen4 and earlier pipe_bpp limiter
code.
v4: Drop the hunk in intel_hdmi.c about g4x/vlv 12bpc, it was wrong.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- There is no 16bpc linear color format in our hw. gen4+ has a 16 bpc
float layout, but we don't really support it.
- 10bpc is a gen4+ feature, fix up the support for it.
- Update_plane should never see a wrong fb bpp value, BUG in the
corresponding cases.
v2: Rebase on top of Ville's plane pixel layout changes.
v3: Actually drop the old gen4 check for 10bpc planes, spotted
by Ville Syrjälä.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The old code only handled either 6bpc or 8bpc. Since it's easy to do,
reorganize the code to be a bit more generic so that it can also handle
10bpc and 12bpc. Note that we still start with 8bpc, so there's no
functional change.
Also, since we no don't need to compute the 6BPC flag in the mode_valid
callback, we can consolidate things a bit. That requires though that
the link bw computation is moved up in the compute_config callback.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we have a useful struct for this, let's use it. Some neat
pointer-chasing required, but it's all there already.
v2: Rebased on top of the added Haswell limited color range support.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is used way too often in the enable/disable paths. And will
be even more useful in the future.
Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set and ->enable with the new config.
v2: Do not yet use the flag in the ->disable callbacks - atm we don't
yet have support for the information stored in the pipe_config in the
hw state readout code, so this will be wrong at boot-up/resume.
v3: Rebased on top of the hdmi/dp ddi encoder merging.
v4: Fixup stupid rebase error which lead to a NULL vfunc deref.
v5: On haswell the VGA port is on the PCH!
v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing
parameter name in a function declaration.
v7: Don't forget to git add ...
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Used by SDVO (and hopefully, eventually HDMI, if we ever get around
to fixing up the low dotclock CEA modes ...).
This required adding a new encoder->mode_set callback to be able to
pass around the intel_crtc_config.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only used by the lvds encoder. Note that we shouldn't do the same
simple conversion with the FORCE_6BPC flag, since that's much better
handled by moving all the pipe_bpc computation around.
This requires that we pass the pipe config around to encoders, so
that they can set special attributes and set constraints. To do so
introduce a new ->compute_config encoder callback, which is called in
stead of the drm crtc helper's ->mode_fixup.
To avoid massive churn all over the codebase we don't want to convert
all existing ->mode_fixup functions. Instead I've opted to convert
them on an as-needed basis (mostly to cut down on rebase conflicts and
to have more freedom to experiment around while developing the
patches).
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To make decent modeset state checking possible (e.g. for the check
mode with atomic modesetting) we want to have the full pipe
configuration and state checks done before we touch the hw.
To ensure that all the little bits&pieces that are now moved to the
pipe_config handle this correctly, move its computation to the right
spot now, before we touch the hw in the disable_pipes step.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently only containing the requested and the adjusted mode. And
only crtc callbacks are converted somewhat to it, encoders will be
done on a as-needed basis (simply too much churn in one patch
otherwise).
Future patches will add tons more useful stuff to this struct,
starting with the very simple.
v2: Store the pipe_config in the intel_crtc, so that the ->mode-set,
->enable and also ->disable have easy access to it.
v3: Store the pipe config in the right crtc ...
v4: Rebased.
v5: Fixup an OOPS when trying to kfree an ERR_PTR.
v6: Used drm_moode_copy and some other small cleanups as suggested
by Ville Syrjälä.
v7: drm_mode_copy preserves the mode id of the destination, so no need
to clear it again (Ville).
v8: Break a long line spotted by Paulo.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From the w/a database:
'To prevent false VT-d type 6 error:
The primary display plane must be 256KiB aligned, and require an extra
128 PTEs of padding afterward;
The sprites planes must be 128KiB aligned, and require an extra 64 PTEs
of padding afterward;
The cursors must be 64KiB aligned, and require an extra 2 PTEs of
padding afterward.'
As we use the same function to pin the primary and sprite planes, we can
simply use the more strict requirements for scanouts for both.
Instead of using explicit padding PTEs following the scanout objects, we
should be able to use the scratch page that is always mapped into the
unused PTEs to avoid the VT-d error.
References: https://bugs.freedesktop.org/show_bug.cgi?id=59626
References: https://bugs.freedesktop.org/show_bug.cgi?id=59627
References: https://bugs.freedesktop.org/show_bug.cgi?id=59631
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Apply s/vtd_wa/vtd_scanout_wa/ bikeshed since Damien likes
it, too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needed for VT switchless resume.
v2: cursor state is now handled correctly in crtc_enable (Daniel)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit cc464b2a17.
The reason is that Takashi Iwai reported a regression bisected to this
commit:
http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html
His machine has eDP on port D (usual desktop all-in-on setup), which
intel_dp.c identifies as an eDP panel, but the hsw ddi code
mishandles.
Closer inspection of the code reveals that haswell_crtc_mode_set also
checks intel_encoder_is_pch_edp when setting is_cpu_edp. On haswell
that doesn't make much sense (since there's no edp on the pch), but
what this function _really_ checks is whether that edp connector is on
port A or port D. It's just that on ilk-ivb port D was on the pch ...
So that explains why this seemingly innocent change killed eDP on port
D. Furthermore it looks like everything else accidentally works, since
we've never enabled eDP on port D support for hsw intentionally (e.g.
we still register the HDMI output for port D in that case).
But in retrospective I also don't like that this leaks highly platform
specific details into common code, and the reason is that the drm
vblank layer sucks. So instead I think we should:
- move the cpu_transcoder into the dynamic pipe_config tracking (once
that's merged).
- fix up the drm vblank layer to finally deal with kms crtc objects
instead of int pipes.
v2: Pimp commit message with the better diagnosis as discussed with
Paulo on irc.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when capturing the error state. This solves some
"unclaimed register" messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The first version of commit "drm/i915: there's no DSPADDR register on
Haswell" added 2 "!IS_HASWELL" checks. When reviewing the patch, Ben
suggested to make these checks more future-proof, so when Daniel
applied the patch he fixed the first check but not the second. This
commit makes the second check also "future-proof".
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We are really talking about the transcoder function here and the disable
version uses trancoder in its name already, so let's try to be
consistent.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the case where the hardware has been wrongly programmed and the EDP
TRANS_DDI_FUNC_CTL register has a bogus value in its EDP Input field, we
were using the pipe variable uninitialized.
In this case, shutdown the transcoder. It will be programmed correctly
the next time we try to enabled eDP.
Note from Paulo's review: Wrong modeset sequence can easily lead to
frozen machines hence the disable_ddi call might be risky. But since
things are awry already, doesn't matter too much.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about Paulo's caution about potential hangs.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This comment looks like some historical leftover. Get rid of it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Port C is for eDP. Port B is shared between HDMI and DP.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Planes are fixed to pipes in VLV.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQEcBAABAgAGBQJRRkrbAAoJEHm+PkMAQRiGy3oH/jrbHinYs0auurANgx4TdtWT
/WNajstKBqLOJJ6cnTR7sOqwOVlptt65EbbTs+qGyZ2Z2W/Lg0BMenHvNHo4ER8C
e7UbMdBCSLKBjAMKh1XCoZscGv4Exm8WRH3Vc5yP0Hafj3EzSAVLY1dta9WKKoQi
bh7D1ErUlbU1zczA1w5YbPF0LqFKRvyZOwebMCCAKAxv5wWAxmbcPNxVR4sufkjg
k6TkQ2ysgWivZAfy3tJYOcxiEu7ahpZVEuYdlZEJQXHRQUfoNljQlOp4BqKsYUai
5A0kaf2VpKay/7pkhvTfBBcF/jFJ68pYP6gQ2ThNdr0b5kOiAfMWj030Xyngnhg=
=iO9t
-----END PGP SIGNATURE-----
Merge tag 'v3.9-rc3' into drm-intel-next-queued
Backmerge so that I can merge Imre Deak's coalesced sg entries fixes,
which depend upon the new for_each_sg_page introduce in
commit a321e91b6d
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Feb 27 17:02:56 2013 -0800
lib/scatterlist: add simple page iterator
The merge itself is just two trivial conflicts:
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when we hang the GPU. This solves "unclaimed
register" messages.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Future-proof by adding a gen >= 7 check in addition to the
!IS_HSW check from Paulo's original patch, suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't read it when capturing the error state. This solves some
"unclaimed register" messages on Haswell when we hang the GPU.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This solves some "unclaimed register" messages when there's a GPU hang
on Haswell.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add missing IS_VLV check as spotted by Ville Syrjälä.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A bunch of fixes, nothing truely horrible:
- Fix PCH irq handling race which resulted in missed gmbus/dp aux irqs
and subsequent fallout (Paulo)
- Fixup off-by-one in our hsw id table (Kenneth)
- Fixup ilk rc6 support (disabled by default), regression introduced in
3.8
- g4x plane w/a from Egbert Eich
- gen2/3/4 dpms suspend/standy fixes for VGA outputs from Patrik Jakobsson
- Workaround dying ivb machines with less aggressive rc6 values (Stéphane
Marchesin)
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Turn off hsync and vsync on ADPA when disabling crt
drm/i915: Fix incorrect definition of ADPA HSYNC and VSYNC bits
drm/i915: also disable south interrupts when handling them
drm/i915: enable irqs earlier when resuming
drm/i915: Increase the RC6p threshold.
DRM/i915: On G45 enable cursor plane briefly after enabling the display plane.
drm/i915: Fix Haswell/CRW PCI IDs.
drm/i915: Don't clobber crtc->fb when queue_flip fails
drm/i915: wait_event_timeout's timeout is in jiffies
drm/i915: Fix missing variable initilization
Some HDMI registers can be used for SDVO, so saying "HDMIB" should be
the same as saying "SDVOB" for a given HW generation. This was not
true and led to confusions and even a regression.
Previously we had:
- SDVO{B,C} defined as the Gen3+ registers
- HDMI{B,C,D} and PCH_SDVOB defined as the PCH registers
But now:
- SDVO{B,C} became GEN3_SDVO{B,C} on SDVO code
- SDVO{B,C} became GEN4_HDMI{B,C} on HDMI code
- HDMI{B,C,D} became PCH_HDMI{B,C,D}
- PCH_SDVOB is still the same thing
v2: Rebase (v1 was sent in May 2012).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On G45 some low res modes (800x600 and 1024x768) produce a blank
screen when the display plane is enabled with with cursor plane
off.
Experiments showed that this issue occurred when the following
conditions were met:
a. a previous mode had the cursor plane enabled (Xserver).
b. this mode or the previous one was using self refresh. (Thus
the problem was only seen with low res modes).
The screens lit up as soon as the cursor plane got enabled.
Therefore the blank screen occurred only in console mode, not
when running an Xserver.
It also seemed to be necessary to disable self refresh while briefly
enabling the cursor plane.
Signed-off-by: Egbert Eich <eich@suse.com>
Bugzilla: https://bugs.freedesktop.org/attachment.cgi?bugid=61457
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: drop spurious whitespace change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The code is totally obvious so these comments serve no purpose. What's
worse, one of them was wrong. Just remove them.
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>
The load detection code has moved around at some point, but it left
a comment behind. The code now looks to be different enough to make
the comment stale as well. Just remove it.
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>
The proper use of find_pll() isn't always so easy to determine from the
code itself. Some documentation should help.
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>
Restore crtc->fb to the old framebuffer if queue_flip fails.
While at it, kill the pointless intel_fb temp variable.
v2: Update crtc->fb before queue_flip and restore it back
after a failure.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-Tested-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So ditch that if clause from the i8xx pll update code.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Two regressions fixes from snowboarding land
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: Revert hdmi HDP pin checks
drm/i915: Handle untiled planes when computing their offsets
We trim the fb to fit the CRTC by computing the offset of that CRTC to
its nearest tile_row origin. This allows us to use framebuffers that are
larger than the CRTC limits without additional work.
However, we failed to compute the offset for a linear framebuffer
correctly as we treated its x-advance in whole tiles (instead of the
linear increment expected), leaving the CRTC misaligned with its
contents.
Fixes regression from commit c2c7513124
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jul 5 12:17:30 2012 +0200
drm/i915: adjust framebuffer base address on gen4+
v2: Adjust relative x-coordinate after linear alignment (vsyrjala)
v3: Repaint with pokadots (vsyrjala)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So here's my promised pile of fixes for 3.9. I've dropped the core prep
patches for vt-switchless suspend/resume as discussed on irc. Highlights:
- Fix dmar on g4x. Not really gfx related, but I'm fed up with getting
blamed for dmar crapouts.
- Disable wc ptes updates on ilk when dmar is enabled (Chris). So again,
dmar, but this time gfx related :(
- Reduced range support for hsw, using the pipe CSC (Ville).
- Fixup pll limits for gen3/4 (Patrick Jakobsson). The sdvo patch is
already confirmed to fix 2 bug reports, so added cc: stable on that one.
- Regression fix for 8bit fb console (Ville).
- Preserve lane reversal bits on DDI/FDI ports (Damien).
- Page flip vs. gpu hang fixes (Ville). Unfortuntely not quite all of
them, need to decide what to do with the currently still in-flight ones.
- Panel fitter regression fix from Mika Kuoppala (was accidentally left on
on some pipes with the new modset code since 3.7). This also improves
the modeset sequence and might help a few other unrelated issues with
lvds.
- Write backlight regs even harder ... another installement in our eternal
fight against the BIOS and backlights.
- Fixup lid notifier vs. suspend/resume races (Zhang Rui). Prep work for
new ACPI stuff, but closing the race itself seems worthwile on its own.
- A few other small fixes and tiny cleanups all over.
Lots of the patches are cc: stable since I've stalled on a few
not-so-important fixes for 3.8 due to the grumpy noise Linus made.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (33 commits)
intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK
drm/i915: Implement pipe CSC based limited range RGB output
drm/i915: inverted brightness quirk for Acer Aspire 4736Z
drm/i915: Print the hw context status is debugfs
drm/i915: Use HAS_L3_GPU_CACHE in i915_gem_l3_remap
drm/i915: Fix PIPE_CONTROL DW/QW write through global GTT on IVB+
drm/i915: Set i9xx sdvo clock limits according to specifications
drm/i915: Set i9xx lvds clock limits according to specifications
drm/i915: Preserve the DDI link reversal configuration
drm/i915: Preserve the FDI line reversal override bit on CPT
drm/i915: add missing \n to UTS_RELEASE in the error_state
drm: Use C8 instead of RGB332 when determining the format from depth/bpp
drm: Fill depth/bits_per_pixel for C8 format
drm/i915: don't clflush gem objects in stolen memory
drm/i915: Don't wait for page flips if there was GPU reset
drm/i915: Kill obj->pending_flip
drm/i915: Fix a typo in a intel_modeset_stage_output_state() comment
drm/i915: remove bogus mutex_unlock from error-path
drm/i915: Print the pipe control page GTT address
...
GPU reset will drop all flips that are still in the ring. So after the
reset, call update_plane() for all CRTCs to make sure the primary
planes are scanning out from the correct buffer.
Also finish all pending flips. That means user space will get its
page flip events and won't get stuck waiting for them.
v2: Explicitly finish page flips instead of relying on FLIP_DONE
interrupt being generated by the base address update.
v3: Make two loops over crtcs to avoid deadlocks with the crtc mutex
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup long line complaint from checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since obj->pending_flips was never set, intel_pipe_set_base() never
actually waited for pending page flips to complete.
We really do want to wait for the pending flips, because otherwise the
mmio surface base address update could overtake the flip, and you
could end up with an old frame on the screen once the flip really
completes.
Just call intel_crtc_wait_pending_flips() prior to calling
intel_pipe_set_base() instead of calling just intel_finish_fb()
from intel_pipe_set_base(). Moving the call outside of
intel_pipe_set_base() avoids calling it twice from the full
modeset path.
v2: Wait for pending flips w/o holding struct_mutex
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>
HSW no longer has the PIPECONF bit for limited range RGB output.
Instead the pipe CSC unit must be used to perform that task.
The CSC pre offset are set to 0, since the incoming data is full
[0:255] range RGB, the coefficients are programmed to compress the
data into [0:219] range, and then we use either the CSC_MODE black
screen offset bit, or the CSC post offsets to shift the data to
the correct [16:235] range.
Also have to change the confiuration of all planes so that the
data is sent through the pipe CSC unit. For simplicity send the
plane data through the pipe CSC unit always, and in case full
range output is requested, the pipe CSC unit is set up with an
identity transform to pass the plane data through unchanged.
I've been told by some hardware people that the use of the pipe
CSC unit shouldn't result in any measurable increase in power
consumption numbers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If a GPU reset occurs while a page flip has been submitted to the ring,
the flip will never complete once the ring has been reset.
The GPU reset can be detected by sampling the reset_counter before the
flip is submitted, and then while waiting for the flip, the sampled
counter is compared with the current reset_counter value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Move the reset_counter assignment to an earlier place in
common code as discussed on the mailing list.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pending flip mask no longer set anywhere, so trying to wait for
while it's non-zero is a no-op. Remove it completely.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch "drm/i915: disable shared panel fitter for
pipe" we now disable the panel fitter at the right spot in the modeset
sequence in the crtc functions on all platforms. Hence the disabling
in intel_disable_lvds is no longer required and potentially harmful
(since the plane is still enabled at this point).
Similarly on the enabling side we enable the panel fitter in the lvds
callback only once the plane is enabled. Which is too late. Hence move
this into a new intel_pre_enable_lvds callback.
Finally we can ditch lvds_encoder->pfit_dirty - this was required to
work around the crtc helper semantics, but with the new i915 modeset
infrastructure we should enable/disable the pfit only when enabling or
disabling the entire output pipeline. So separate state tracking for
the pfit is no longer required.
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Bikeshed the commit message a bit to stress that now we
enable/disable the pfit on i9xx platforms at the right point of time
compared to the old code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.
Based on work by Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Cc: stable@vger.kernel.org
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
screen).
- It unconditionally sets the fb, even if no mode will be set on a
given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
the desired fb size, but also should set the modeset->fb pointer.
Explain what's going on in the fixup code after the fb is allocated.
The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.
Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.
v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
"Probably the last feature pull for 3.9, there's some fixes outstanding
thought that I'd like to sneak in. And maybe 3.8 takes a bit longer ...
Anyway, highlights of this pull:
- Kill the horrible IS_DISPLAYREG hack to handle the mmio offset movements
on vlv, big thanks to Ville.
- Dynamic power well support for Haswell, shaves away a bit when only
using the eDP port on pipe A (Paulo). Plus unclaimed register fixes
uncovered by this.
- Clarifications of the gpu hang/reset state transitions, hopefully fixing
a few spurious -EIO deaths in userspace.
- Haswell ELD fixes.
- Some more (pp)gtt cleanups from Ben.
- A few smaller things all over.
Plus all the stuff from the previous rather small pull request:
- Broadcast RBG improvements and reduced color range fixes from Ville.
- Ben is on a "kill legacy gtt code for good" spree, first pile of patches
included.
- No-relocs and bo lut improvements for faster execbuf from Chris.
- Some refactorings from Imre."
* tag 'drm-intel-next-2013-02-01' of git://people.freedesktop.org/~danvet/drm-intel: (101 commits)
GPU/i915: Fix acpi_bus_get_device() check in drivers/gpu/drm/i915/intel_opregion.c
drm/i915: Set the SR01 "screen off" bit in i915_redisable_vga() too
drm/i915: Kill IS_DISPLAYREG()
drm/i915: Introduce i915_vgacntrl_reg()
drm/i915: gen6_gmch_remove can be static
drm/i915: dynamic Haswell display power well support
drm/i915: check the power down well on assert_pipe()
drm/i915: don't send DP "idle" pattern before "normal" on HSW PORT_A
drm/i915: don't run hsw power well code on !hsw
drm/i915: kill cargo-culted locking from power well code
drm/i915: Only run idle processing from i915_gem_retire_requests_worker
drm/i915: Fix CAGF for HSW
drm/i915: Reclaim GTT space for failed PPGTT
drm/i915: remove intel_gtt structure
drm/i915: Add probe and remove to the gtt ops
drm/i915: extract hw ppgtt setup/cleanup code
drm/i915: pte_encode is gen6+
drm/i915: vfuncs for ppgtt
drm/i915: vfuncs for gtt_clear_range/insert_entries
drm/i915: Error state should print /sys/kernel/debug
...
From BSpec / SR01 - Clocking Mode:
"The following sequence must be used when disabling the VGA plane.
Write SR01 to set bit 5 = 1 to disable video output.
Wait for 100us.
Disable the VGA plane via Bit 31 of the MMIO VGA control."
So simply call i915_disable_vga() from i915_redisable_vga().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The VGACNTRL register has moved around between different platforms.
To handle the differences add i915_vgacntrl_reg() which returns the
correct offset for the VGACNTRL register.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that early (yet), we need to help us with a trick to simply
check for any edp encoders.
v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.
v3: Made by Paulo Zanoni
- Rebase patch to be on top of "fix intel_init_power_wells" patch
- Fix typos
- Fix a small bug by adding a "connectors_active" check
- Restore the initial code that unconditionally enables the power
well when taking over from the BIOS
v4: Made by Paulo Zanoni
- One more typo spotted by Jani Nikula
v5: Made by Paulo Zanoni
- Rebase
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the power well is disabled, we should not try to read its
registers, otherwise we'll get "unclaimed register" messages.
V2: Don't check whether the power well is enabled or not, just check
whether we asked it to be enabled or not: if we asked to disable the
power well, don't use the registers on it, even if it's still enabled.
V3: Fix bug that breaks all non-Haswell machines.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When adding the fb idle detection to mark-inactive, it was forgotten
that userspace can drive the processing of retire-requests. We assumed
that it would be principally driven by the retire requests worker,
running once every second whilst active and so we would get the deferred
timer for free. Instead we spend too many CPU cycles reclocking the LVDS
preventing real work from being done.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Alexander Lam <lambchop468@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843
Cc: stable@vger.kernel.org
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The only thing we really care about that it is off. To do so, reuse
the recently created i915_redisable_vga function, which is already
used to put obnoxious firmware into check on lid reopening.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of setting it at the beginning of haswell_crtc_mode_set, let's
set it at the beginning of intel_crtc_mode_set. When
intel_crt_mode_set calls drm_vblank_pre_modeset we already need to
have the transcoder_edp correctly set, because eventually
drm_vblank_pre_modeset calls functions that call i915_pipe_enabled
from i915_irq.c, which will read PIPECONF(cpu_transcoder).
This is a bug that affects us since we added support for
TRANSCODER_EDP, but I was only able to see the problem after
suspending a machine with the power well disabled (got an "unclaimed
register" error.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
One of the early return cases missed the mutex unlocking. Hilarity
ensued.
This regression has been introduced in
commit 7b24056be6
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Dec 12 00:35:33 2012 +0100
drm: don't hold crtc mutexes for connector ->detect callbacks
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59750
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Cancan Feng <cancan.feng@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The current code was wrong in many different ways, so this is a full
rewrite. We don't have "different power wells for different parts of
the GPU", we have a single power well, but we have multiple registers
that can be used to request enabling/disabling the power well. So
let's be a good citizen and only use the register we're suppose to
use, except when we're loading the driver, where we clear the request
made by the BIOS.
If any of the registers is requesting the power well to be enabled, it
will be enabled. If none of the registers is requesting the power well
to be enabled, it will be disabled.
For now we're just forcing the power well to be enabled, but in the
next commits we'll change this.
V2:
- Remove debug messages that could be misleading due to possible
race conditions with KVMr, Debug and BIOS.
- Don't wait on disabling: after a conversaion with a hardware
engineer we discovered that the "restriction" on bit 31 is just
for the "enable" case, and we don't even need to wait on the
"disable" case.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When passing the DP/HDMI/SDVO registers to the encoder init functions,
include the VLV specific offset in the value.
v2: Resolved conflicts w/ VLV SDVO elimination
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't call intel_sdvo_init() for VLV.
Preserve the same behaviour as when intel_sdvo_init() would
have returned false.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
commit 09153000b8
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Dec 12 14:06:44 2012 +0100
drm/i915: rework locking for intel_dpio|sbi_read|write
reworked the locking around sbi_read/write functions for 3.8-fixes.
But
commit dde86e2db5
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Sat Dec 1 12:04:25 2012 -0200
drm/i915: add lpt_init_pch_refcl
Added new use-cases in the -next tree which has not been updated in
the merge. Fix it up.
Reported-by: 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>
ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156
Reported-by: Alan Zimmerman <alan.zimm@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35
[Note: There are more than one broken setups in the bug. This fixes one.]
Reported-by: Martins <andrissr@inbox.lv>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628
Reported-by: Roland Gruber <post@rolandgruber.de>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The aim of this locking rework is that ioctls which a compositor should be
might call for every frame (set_cursor, page_flip, addfb, rmfb and
getfb/create_handle) should not be able to block on kms background
activities like output detection. And since each EDID read takes about
25ms (in the best case), that always means we'll drop at least one frame.
The solution is to add per-crtc locking for these ioctls, and restrict
background activities to only use the global lock. Change-the-world type
of events (modeset, dpms, ...) need to grab all locks.
Two tricky parts arose in the conversion:
- A lot of current code assumes that a kms fb object can't disappear while
holding the global lock, since the current code serializes fb
destruction with it. Hence proper lifetime management using the already
created refcounting for fbs need to be instantiated for all ioctls and
interfaces/users.
- The rmfb ioctl removes the to-be-deleted fb from all active users. But
unconditionally taking the global kms lock to do so introduces an
unacceptable potential stall point. And obviously changing the userspace
abi isn't on the table, either. Hence this conversion opportunistically
checks whether the rmfb ioctl holds the very last reference, which
guarantees that the fb isn't in active use on any crtc or plane (thanks
to the conversion to the new lifetime rules using proper refcounting).
Only if this is not the case will the code go through the slowpath and
grab all modeset locks. Sane compositors will never hit this path and so
avoid the stall, but userspace relying on these semantics will also not
break.
All these cases are exercised by the newly added subtests for the i-g-t
kms_flip, tested on a machine where a full detect cycle takes around 100
ms. It works, and no frames are dropped any more with these patches
applied. kms_flip also contains a special case to exercise the
above-describe rmfb slowpath.
* 'drm-kms-locking' of git://people.freedesktop.org/~danvet/drm-intel: (335 commits)
drm/fb_helper: check whether fbcon is bound
drm/doc: updates for new framebuffer lifetime rules
drm: don't hold crtc mutexes for connector ->detect callbacks
drm: only grab the crtc lock for pageflips
drm: optimize drm_framebuffer_remove
drm/vmwgfx: add proper framebuffer refcounting
drm/i915: dump refcount into framebuffer debugfs file
drm: refcounting for crtc framebuffers
drm: refcounting for sprite framebuffers
drm: fb refcounting for dirtyfb_ioctl
drm: don't take modeset locks in getfb ioctl
drm: push modeset_lock_all into ->fb_create driver callbacks
drm: nest modeset locks within fpriv->fbs_lock
drm: reference framebuffers which are on the idr
drm: revamp framebuffer cleanup interfaces
drm: create drm_framebuffer_lookup
drm: revamp locking around fb creation/destruction
drm: only take the crtc lock for ->cursor_move
drm: only take the crtc lock for ->cursor_set
drm: add per-crtc locks
...
The coup de grace of the entire journey. No more dropped frames every
10s on my testbox!
I've tried to audit all ->detect and ->get_modes callbacks, but things
became a bit fuzzy after trying to piece together the umpteenth
implemenation. Afaict most drivers just have bog-standard output
register frobbing with a notch of i2c edid reading, nothing which
could potentially race with the newly concurrent pageflip/set_cursor
code. The big exception is load-detection code which requires a
running pipe, but radeon/nouveau seem to to this without touching any
state which can be observed from page_flip (e.g. disabled crtcs
temporarily getting enabled and so a pageflip succeeding).
The only special case I could find is the i915 load detect code. That
uses the normal modeset interface to enable the load-detect crtc, and
so userspace could try to squeeze in a pageflip on the load-detect
pipe. So we need to grab the relevant crtc mutex in there, to avoid
the temporary crtc enabling to sneak out and be visible to userspace.
Note that the sysfs files already stopped grabbing the per-crtc locks,
since I didn't want to bother with doing a interruptible
modeset_lock_all. But since there's very little in-between breakage
(essentially just the ability for userspace to pageflip on load-detect
crtcs when it shouldn't on the i915 driver) I figured I don't need to
bother.
Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have two classes of framebuffer
- Created by the driver (atm only for fbdev), and the driver holds
onto the last reference count until destruction.
- Created by userspace and associated with a given fd. These
framebuffers will be reaped when their assoiciated fb is closed.
Now these two cases are set up differently, the framebuffers are on
different lists and hence destruction needs to clean up different
things. Also, for userspace framebuffers we remove them from any
current usage, whereas for internal framebuffers it is assumed that
the driver has done this already.
Long story short, we need two different ways to cleanup such drivers.
Three functions are involved in total:
- drm_framebuffer_remove: Convenience function which removes the fb
from all active usage and then drops the passed-in reference.
- drm_framebuffer_unregister_private: Will remove driver-private
framebuffers from relevant lists and drop the corresponding
references. Should be called for driver-private framebuffers before
dropping the last reference (or like for a lot of the drivers where
the fbdev is embedded someplace else, before doing the cleanup
manually).
- drm_framebuffer_cleanup: Final cleanup for both classes of fbs,
should be called by the driver's ->destroy callback once the last
reference is gone.
This patch just rolls out the new interfaces and updates all drivers
(by adding calls to drm_framebuffer_unregister_private at all the
right places)- no functional changes yet. Follow-on patches will move
drm core code around and update the lifetime management for
framebuffers, so that we are no longer required to keep framebuffers
alive by locking mode_config.mutex.
I've also updated the kerneldoc already.
vmwgfx seems to again be a bit special, at least I haven't figured out
how the fbdev support in that driver works. It smells like it's
external though.
v2: The i915 driver creates another private framebuffer in the
load-detect code. Adjust its cleanup code, too.
Reviewed-by: Rob Clark <rob@ti.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With more fine-grained locking we can no longer rely on the big
mode_config lock to prevent concurrent access to mode resources
like framebuffers. Instead a framebuffer becomes accessible to
other threads as soon as it is added to the relevant lookup
structures. Hence it needs to be fully set up by the time drivers
call drm_framebuffer_init.
This patch here is the drivers part of that reorg. Nothing really fancy
going on safe for three special cases.
- exynos needs to be careful to properly unref all handles.
- nouveau gets a resource leak fixed for free: one of the error
cases didn't cleanup the framebuffer, which is now moot since
the framebuffer is only registered once it is fully set up.
- vmwgfx requires a slight reordering of operations, I'm hoping I didn't
break anything (but it's refcount management only, so should be safe).
v2: Split out exynos, since it's a bit more hairy than expected.
v3: Drop bogus cirrus hunk noticed by Richard Wilbur.
v4: Split out vmwgfx since there's a small change in return values.
Reviewed-by: Rob Clark <rob@ti.com> (core + omapdrm)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have two important transitions of the wedged state in the current
code:
- 0 -> 1: This means a hang has been detected, and signals to everyone
that they please get of any locks, so that the reset work item can
do its job.
- 1 -> 0: The reset handler has completed.
Now the last transition mixes up two states: "Reset completed and
successful" and "Reset failed". To distinguish these two we do some
tricks with the reset completion, but I simply could not convince
myself that this doesn't race under odd circumstances.
Hence split this up, and add a new terminal state indicating that the
hw is gone for good.
Also add explicit #defines for both states, update comments.
v2: Split out the reset handling bugfix for the throttle ioctl.
v3: s/tmp/wedged/ sugested by Chris Wilson. Also fixup up a rebase
error which prevented this patch from actually compiling.
v4: To unify the wedged state with the reset counter, keep the
reset-in-progress state just as a flag. The terminally-wedged state is
now denoted with a big number.
v5: Add a comment to the reset_counter special values explaining that
WEDGED & RESET_IN_PROGRESS needs to be true for the code to be
correct.
v6: Fixup logic errors introduced with the wedged+reset_counter
unification. Since WEDGED implies reset-in-progress (in a way we're
terminally stuck in the dead-but-reset-not-completed state), we need
ensure that we check for this everywhere. The specific bug was in
wait_for_error, which would simply have timed out.
v7: Extract an inline i915_reset_in_progress helper to make the code
more readable. Also annote the reset-in-progress case with an
unlikely, to help the compiler optimize the fastpath. Do the same for
the terminally wedged case with i915_terminally_wedged.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And to make Ben Widawsky happier, use the gpu_error instead of
the entire device as the argument in some functions.
Drop the outdated comment on ->wedged for now, a follow-up patch will
change the semantics and add a proper comment again.
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.
Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.
Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.
The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.
TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
volunteer to test if it's just a documentation issue or if it's really
gone. If the bit is gone and no easy replacement is found, then I suppose
we may need to use the pipe CSC unit to perform the range compression.
v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
later patches
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The purpose of the gtt structure is to help isolate our gtt specific
properties from the rest of the code (in doing so it help us finish the
isolation from the AGP connection).
The following members are pulled out (and renamed):
gtt_start
gtt_total
gtt_mappable_end
gtt_mappable
gtt_base_addr
gsm
The gtt structure will serve as a nice place to put gen specific gtt
routines in upcoming patches. As far as what else I feel belongs in this
structure: it is meant to encapsulate the GTT's physical properties.
This is why I've not added fields which track various drm_mm properties,
or things like gtt_mtrr (which is itself a pretty transient field).
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[Ben modified commit messages]
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise it seems like we can get stuck with concurrent waiters.
Right now this /shouldn't/ be a problem, since all pending pageflip
waiters are serialized by the one mode_config.mutex, so there's at
most on waiter. But better paranoid than sorry, since this is tricky
code.
v2: WARN_ON(waitqueue_active) before waiting, as suggested by Chris
Wilson.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
- seqno wrap fixes and debug infrastructure from Mika Kuoppala and Chris
Wilson
- some leftover kill-agp on gen6+ patches from Ben
- hotplug improvements from Damien
- clear fb when allocated from stolen, avoids dirt on the fbcon (Chris)
- Stolen mem support from Chris Wilson, one of the many steps to get to
real fastboot support.
- Some DDI code cleanups from Paulo.
- Some refactorings around lvds and dp code.
- some random little bits&pieces
* tag 'drm-intel-next-2012-12-21' of git://people.freedesktop.org/~danvet/drm-intel: (93 commits)
drm/i915: Return the real error code from intel_set_mode()
drm/i915: Make GSM void
drm/i915: Move GSM mapping into dev_priv
drm/i915: Move even more gtt code to i915_gem_gtt
drm/i915: Make next_seqno debugs entry to use i915_gem_set_seqno
drm/i915: Introduce i915_gem_set_seqno()
drm/i915: Always clear semaphore mboxes on seqno wrap
drm/i915: Initialize hardware semaphore state on ring init
drm/i915: Introduce ring set_seqno
drm/i915: Missed conversion to gtt_pte_t
drm/i915: Bug on unsupported swizzled platforms
drm/i915: BUG() if fences are used on unsupported platform
drm/i915: fixup overlay stolen memory leak
drm/i915: clean up PIPECONF bpc #defines
drm/i915: add intel_dp_set_signal_levels
drm/i915: remove leftover display.update_wm assignment
drm/i915: check for the PCH when setting pch_transcoder
drm/i915: Clear the stolen fb before enabling
drm/i915: Access to snooped system memory through the GTT is incoherent
drm/i915: Remove stale comment about intel_dp_detect()
...
Conflicts:
drivers/gpu/drm/i915/intel_display.c
This proves to be very useful when investigating why code suddenly
started failing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a regression from
commit 57779d0636
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Oct 31 17:50:14 2012 +0200
drm/i915: Fix display pixel format handling
(which even says that they are supported on Ironlake, and then promptly
rejects then...)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some fixes for 3.8:
- Watermark fixups from Chris Wilson (4 pieces).
- 2 snb workarounds, seem to be recently added to our internal DB.
- workaround for the infamous i830/i845 hang, seems now finally solid!
Based on Chris' fix for SNA, now also for UXA/mesa&old SNA.
- Some more fixlets for shrinker-pulls-the-rug issues (Chris&me).
- Fix dma-buf flags when exporting (you).
- Disable the VGA plane if it's enabled on lid open - similar fix in
spirit to the one I've sent you last weeek, BIOS' really like to mess
with the display when closing the lid (awesome debug work from Krzysztof
Mazur).
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915: disable shrinker lock stealing for create_mmap_offset
drm/i915: optionally disable shrinker lock stealing
drm/i915: fix flags in dma buf exporting
i915: ensure that VGA plane is disabled
drm/i915: Preallocate the drm_mm_node prior to manipulating the GTT drm_mm manager
drm: Export routines for inserting preallocated nodes into the mm manager
drm/i915: don't disable disconnected outputs
drm/i915: Implement workaround for broken CS tlb on i830/845
drm/i915: Implement WaSetupGtModeTdRowDispatch
drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled
drm/i915: Prefer CRTC 'active' rather than 'enabled' during WM computations
drm/i915: Clear self-refresh watermarks when disabled
drm/i915: Double the cursor self-refresh latency on Valleyview
drm/i915: Fixup cursor latency used for IVB lp3 watermarks
Note: This patch also adds a little helper intel_crtc_restore_mode for
the common case where we do a full modeset but with the same
parameters, e.g. to undo bios damage or update a property.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Added note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Some broken systems (like HP nc6120) in some cases, usually after LID
close/open, enable VGA plane, making display unusable (black screen on LVDS,
some strange mode on VGA output). We used to disable VGA plane only once at
startup. Now we also check, if VGA plane is still disabled while changing
mode, and fix that if something changed it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57434
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This piece of neat lore has been ported painstakingly and bug-for-bug
compatible from the old crtc helper code.
Imo it's utter nonsense.
If you disconnected a cable and before you reconnect it, userspace (or
the kernel) does an set_crtc call, this will result in that connector
getting disabled. Which will result in a nice black screen when
plugging in the cable again.
There's absolutely no reason the kernel does such policy enforcements
- if userspace tries to set up a mode on something disconnected we
might fail loudly (since the dp link training fails), but silently
adjusting the output configuration behind userspace's back is a recipe
for disaster. Specifically I think that this could explain some of our
MI_WAIT hangs around suspend, where userspace issues a scanline wait
on a disable pipe. This mechanisims here could explain how that pipe
got disabled without userspace noticing.
Note that this fixes a NULL deref at BIOS takeover when the firmware
sets up a disconnected output in a clone configuration with a
connected output on the 2nd pipe: When doing the full modeset we don't
have a mode for the 2nd pipe and OOPS. On the first pipe this doesn't
matter, since at boot-up the fbdev helpers will set up the choosen
configuration on that on first. Since this is now the umptenth bug
around handling this imo brain-dead semantics correctly, I think it's
time to kill it and see whether there's any userspace out there which
relies on this.
It also nicely demonstrates that we have a tiny window where DP
hotplug can still kill the driver.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58396
Cc: stable@vger.kernel.org
Tested-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to clean up the overlay first, before taking down the
stolen memory allocator.
This regression has been introducec in
commit 8040513870
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 15 11:32:29 2012 +0000
drm/i915: Allocate overlay registers from stolen memory
v2: Rework the patch a bit as suggested by Chris Wilson:
- move the overlay teardown up, into the modeset cleanup
- move the stolen mm takedown into i915_gem_cleanup_stolen
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ilk+ somehow used #defines in near the PIPESTAT definitions, which
decently confused me. Earlier platforms called it BPP instead of
BPC. Clean this all up.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Don't check the CPU, it doesn't have any PCH transcoder.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel writes:
A few leftover fixes for 3.8:
- VIC support for hdmi infoframes with the associated drm helper, fixes
some black TVs (Paulo Zanoni)
- Modeset state check (and fixup if the BIOS messed with the hw) for
lid-open. modeset-rework fallout. Somehow the original reporter went
awol, so this stalled for way too long until we've found a new
victim^Wreporter with broken BIOS.
- seqno wrap fixes from Mika and Chris.
- Some minor fixes all over from various people.
- Another race fix in the pageflip vs. unpin code from Chris.
- hsw vga resume support and a few more fdi link fixes (only used for vga
on hsw) from Paulo.
- Regression fix for DMAR from Zhenyu Wang - I've scavenged memory from my
DMAR for a while and it broke right away :(
- Regression fix from Takashi Iwai for ivb lvds - some w/a needs to be
(partially) moved back into place. Note that these are regressions in
-next.
- One more fix for ivb 3 pipe support - it now actually seems to work.
* 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: (25 commits)
drm/i915: Fix missed needs_dmar setting
drm/i915: Fix shifted screen on top of LVDS on IVY laptop
drm/i915: disable cpt phase pointer fdi rx workaround
drm/i915: set the LPT FDI RX polarity reversal bit when needed
drm/i915: add lpt_init_pch_refclk
drm/i915: add support for mPHY destination on intel_sbi_{read, write}
drm/i915: reject modes the LPT FDI receiver can't handle
drm/i915: fix hsw_fdi_link_train "retry" code
drm/i915: Close race between processing unpin task and queueing the flip
drm/i915: fixup l3 parity sysfs access check
drm/i915: Clear the existing watermarks for g4x when modifying the cursor sr
drm/i915: do not access BLC_PWM_CTL2 on pre-gen4 hardware
drm/i915: Don't allow ring tail to reach the same cacheline as head
drm/i915: Decouple the object from the unbound list before freeing pages
drm/i915: Set sync_seqno properly after seqno wrap
drm/i915: Include the last semaphore sync point in the error-state
drm/i915: Rearrange code to only have a single method for waiting upon the ring
drm/i915: Simplify flushing activity on the ring
drm/i915: Preallocate next seqno before touching the ring
drm/i915: force restore on lid open
...
CPT+ PCHs have different bit definition to read the HPD live status. I
don't have an ILK with digital ports handy, which is why this patch is
separate from the CPT+ implementation. If the docs don't lie, it should
all be fine though.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If you unplug the hdmi connector slowly enough, the hotplug interrupt
fires but then the kernel code tries to read the EDID and succeeds
(because the connector is still half connected, the HPD pin is shorter
than the others, and DDC works). Since EDID succeeds it thinks the
monitor is still connected.
To prevent that, read the live HPD status in the hotplug handler before
trying to read the EDID.
v2: Rename the function to ibx_ (Chris Wilson)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55372
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Spinning for up to 200 us with interrupts locked out is not good. So
let's just spin (and even that seems to be excessive).
And we don't call these functions from interrupt context, so this is
not required. Besides that doing anything in interrupt contexts which
might take a few hundred us is a no-go. So just convert the entire
thing to a mutex. Also move the mutex-grabbing out of the read/write
functions (add a WARN_ON(!is_locked)) instead) since all callers are
nicely grouped together.
Finally the real motivation for this change: Dont grab the modeset
mutex in the dpio debugfs file, we don't need that consistency. And
correctness of the dpio interface is ensured with the dpio_lock.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We've originally added this in
commit 291427f5fd
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Jul 29 12:42:37 2011 -0700
drm/i915: apply phase pointer override on SNB+ too
and then copy-pasted it over to ivb/ppt. The w/a was originally added
for ilk/ibx in
commit 5b2adf8971
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Oct 7 16:01:15 2010 -0700
drm/i915: add Ironlake clock gating workaround for FDI link training
and fixed up a bit in
commit 6f06ce184c
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Tue Jan 4 15:09:38 2011 -0800
drm/i915: set phase sync pointer override enable before setting phase sync pointer
It turns out that this w/a isn't actually required on cpt/ppt and
positively harmful on ivb/ppt when using fdi B/C links - it results in
a black screen occasionally, with seemingfully everything working as
it should. The only failure indication I've found in the hw is that
eventually (but not right after the modeset completes) a pipe underrun
is signalled.
Big thanks to Arthur Runyan for all the ideas for registers to check
and changes to test, otherwise I couldn't ever have tracked this down!
Cc: "Runyan, Arthur J" <arthur.j.runyan@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need this code to init the PCH SSC refclk and the FDI registers.
The BIOS does this too and that's why VGA worked before this patch,
until you tried to suspend the machine...
This patch implements the "Sequence to enable CLKOUT_DP for FDI usage
and configure PCH FDI/IO" from our documentation.
v2:
- Squash Damien Lespiau's reset spelling fix on top.
- Add a comment that we don't need to bother about the ULT special
case Damien noticed, since ULT won't have VGA.
- Add a comment to rip out the SDV codepaths once haswell ships for
real.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Alex writes:
Pretty minor -next pull request. We some additional new bits waiting
internally for release. Hopefully Monday we can get at least some of
them out. The others will probably take a few more weeks.
Highlights of the current request:
- ELD registers for passing audio information to the sound hardware
- Handle GPUVM page faults more gracefully
- Misc fixes
Merge radeon test
* 'drm-next-3.8' of git://people.freedesktop.org/~agd5f/linux: (483 commits)
drm/radeon: bump driver version for new info ioctl requests
drm/radeon: fix eDP clk and lane setup for scaled modes
drm/radeon: add new INFO ioctl requests
drm/radeon/dce32+: use fractional fb dividers for high clocks
drm/radeon: use cached memory when evicting for vram on non agp
drm/radeon: add a CS flag END_OF_FRAME
drm/radeon: stop page faults from hanging the system (v2)
drm/radeon/dce4/5: add registers for ELD handling
drm/radeon/dce3.2: add registers for ELD handling
radeon: fix pll/ctrc mapping on dce2 and dce3 hardware
Linux 3.7-rc7
powerpc/eeh: Do not invalidate PE properly
Revert "drm/i915: enable rc6 on ilk again"
ALSA: hda - Fix build without CONFIG_PM
of/address: sparc: Declare of_iomap as an extern function for sparc again
PM / QoS: fix wrong error-checking condition
bnx2x: remove redundant warning log
vxlan: fix command usage in its doc
8139cp: revert "set ring address before enabling receiver"
MPI: Fix compilation on MIPS with GCC 4.4 and newer
...
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_encoder.c
drivers/gpu/drm/exynos/exynos_drm_fbdev.c
drivers/gpu/drm/nouveau/core/engine/disp/nv50.c
This way we should be able to write mPHY registers using the Sideband
Interface in the next commit. Also fixed some syntax oddities in the
related code.
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>
smatch warning:
drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts
500 bytes on stack
Refactor so that saved_mode and saved_hwmode are dynamically allocated as opposed
to being automatic variables. 500 bytes seems like it could run the potential for blowing
the kernel stack.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
More specifically, the LPT FDI RX only supports 8bpc and a maximum of
2 lanes, so anything above that won't work and should be rejected.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Both the dp and fdi code use the exact same computations (ignore minor
differences in conversion between bits and bytes).
This makes it even more apparent that we have a _massive_ mess between
cpu transcoder/fdi link/pch transcoder and pch link settings. And also
that we have hilarious amounts of confusion between edp and dp
(despite that they're identical at a link level).
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This has originally been added in
commit 8db9d77b1b
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date: Wed Apr 7 16:15:54 2010 +0800
drm/i915: Support for Cougarpoint PCH display pipeline
probably to combat issues with hw state left behind by the BIOS. And
indeed, I've checked out that specific revision, and there is no DP
support yet. So the pch dp transcoder won't be correctly disabled, and
that's important since it requires a rether special disable dance:
Just writing 0 to TRANS_DP_CTL won't cut it, since we need to select
the NONE port when disabling, too.
And indeed, things seem to still work, so let's just remove this.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we enable the cpu edp pll in intel_dp->pre_enable and no
longer in crtc_mode_set, we can also move the modeset part to the
intel_dp->mode_set callback. Previously this was not possible because
the encoder ->mode_set callbacks are called after the crtc mode set
callback.
v2: Rebase on top of copy&pasted hsw crtc_mode_set.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Especially getting rid of all things lvds is ... great!
v2: Drop the two additional pre-hsw hunks noticed by Paulo Zanoni.
v3:
- handle DP ports correctly (spoted by Paulo)
- don't leave {} behind for a single-line block (again spotted by
Paulo)
- kill another if (IBX || CPT) block
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Before queuing the flip but crucially after attaching the unpin-work to
the crtc, we continue to setup the unpin-work. However, should the
hardware fire early, we see the connected unpin-work and queue the task.
The task then promptly runs and unpins the fb before we finish taking
the required references or even pinning it... Havoc.
To close the race, we use the flip-pending atomic to indicate when the
flip is finally setup and enqueued. So during the flip-done processing,
we can check more accurately whether the flip was expected.
v2: Add the appropriate mb() to ensure that the writes to the page-flip
worker are complete prior to marking it active and emitting the MI_FLIP.
On the read side, the mb should be enforced by the spinlocks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Review the barriers a bit, we need a write barrier both
before and after updating ->pending. Similarly we need a read barrier
in the interrupt handler both before and after reading ->pending. With
well-ordered irqs only one barrier in each place should be required,
but since this patch explicitly sets out to combat spurious interrupts
with is staged activation of the unpin work we need to go full-bore on
the barriers, too. Discussed with Chris Wilson on irc and changes
acked by him.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- __iomem where there is none (I love how we mix these things up).
- Use gfp_t instead of an other plain type.
- Unconfuse one place about enum pipe vs enum transcoder - for the pch
transcoder we actually use the pipe enum. Fixup the other cases
where we assign the pipe to the cpu transcoder with explicit casts.
- Declare the mch_lock properly in a header.
There is still a decent mess in intel_bios.c about __iomem, but heck,
this is x86 and we're allowed to do that.
Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use a space after the cast consistently and fix up the
newly-added cast in i915_irq.c to properly use __iomem.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As FBC is commonly disabled due to limitations of the chipset upon
output configurations, on many systems FBC is never enabled. For those
systems, it is advantageous to make use of the stolen memory for other
objects and so we defer allocation of the FBC chunk until we actually
require it. This increases the likelihood of that allocation failing,
but that in turns means that we are already taking advantage of the
stolen memory!
As well as delaying the allocation from driver initialisation until the
first use of FBC, we also return the stolen block after we finish using
it - allowing greater flexibility in our usage of stolen space. A side
effect of this is that we can then attempt to allocate only the required
amount of space (with a little slack to reduce reallocation rate and
avoid fragmentation).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is not called on Haswell anymore.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Only two things needed adjustment:
- pipe select for PCH_CPT
- There's no dithering bit on ilk+ in the lvds ctl reg
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A few things needed to change:
- HAS_PCH_SPLIT since ilk+ is not yet converted to this.
- s/LVDS/intel_lvds->reg/ to prep for ilk conversion
- replace the clock.p2 == 7 check with a is_dual_link check
- s/adjusted_mode/intel_lvds->fixed_mode
v2: Rebase on top of Jani Nikula's panel rework. I'm wondering whether
we shouldn't add an attached_panel pointer to intel_encoder, to
replace the encoder private ->attached_connector pointers, since
that's essentially what we need.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just a prep patch to make this a property of intel_lvds. Makes more
sense, removes clutter from intel_display.c and eventually I want to
move all the encoder special cases wrt clock handling to encoders
anyway.
v2: Add an intel_ prefixe to is_dual_link_lvds since it's non-static
now.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
