Daniel Vetter [Mon, 29 Apr 2013 17:33:42 +0000 (19:33 +0200)]
drm/i915: hw state readout support for pipe_config->fdi_lanes
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>
Daniel Vetter [Wed, 13 Feb 2013 17:04:45 +0000 (18:04 +0100)]
drm/i915: move intel_crtc->fdi_lanes to pipe_config
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>
Daniel Vetter [Fri, 19 Apr 2013 09:24:38 +0000 (11:24 +0200)]
drm/i915: allow high-bpc modes on DP
Totally untested due to lack of screens supporting more than 8bpc. But
now we should have closed all holes in our bpp handling, so this
should be safe. The last missing piece was 10bpc support for g4x/vlv,
since we directly use the pipe bpp to feed the display link (and
anyway, only the cpt has any means to have a pipe bpp != the display
link bpp).
Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 24 Apr 2013 12:57:17 +0000 (14:57 +0200)]
drm/i915: implement high-bpc + pipeconf-dither support for g4x/vlv
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>
Daniel Vetter [Tue, 19 Feb 2013 16:45:00 +0000 (17:45 +0100)]
drm/i915: force bpp for eDP panels
We've had our fair share of woes already which showed that we can't
rely on the bpc limits in the EDID for eDP panels without risking
black screens. So now we limit the depth by what the BIOS recommends
in the VBT:
But that's not enough, since at least the panel on my ASUS Zenbook
Prime here is also unhappy if the bpc is too low. Hence just take the
firmware value and dither to get what flimsy panels want.
Like before we ensure that we don't change the bpp if the firmware
doesn't provide a value, see
drm/i915: do not default to 18 bpp for eDP if missing from VBT
v2: Apparently there are some horribly broken eDP panels around which
only work if the DP link is set up as if we want to driver a 24bpp
mode, but still only work if the data is feed at 18bpp. See
Adjust the patch accordingly and update all the relevant comments.
v3: Give up on the cargo-culting v2 attempt and just enfore the edp
bpp value if it's there. Broken panels be damned!
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Sat, 27 Apr 2013 11:44:16 +0000 (12:44 +0100)]
drm/i915: Only print the info message about incresing stolen size for FBC once
Instead of repeatedly bombarding the user with a request to reboot and
increase the stolen size with every fb refresh, just inform them the
first time only.
v2: Rearrange code so the hint to increase the amount of memory stolen
by the BIOS is only emitted if we fail to find sufficient stolen memory
for FBC.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Fixup formatting code mismatch that gcc spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: factor out GMCH panel fitting code and use for eDP v3
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>
Daniel Vetter [Fri, 19 Apr 2013 09:14:35 +0000 (11:14 +0200)]
drm/i915: don't force matching p1 for g4x/ilk+ reduced pll settings
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
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>
Daniel Vetter [Thu, 25 Apr 2013 15:54:44 +0000 (17:54 +0200)]
drm/i915: use pipe_config for lvds dithering
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>
Daniel Vetter [Fri, 19 Apr 2013 09:14:33 +0000 (11:14 +0200)]
drm/i915: move dp clock computations to encoder->compute_config
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>
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>
Jani Nikula [Fri, 12 Apr 2013 12:20:57 +0000 (15:20 +0300)]
drm/i915/opregion: don't pretend we did something when we didn't
In theory, the BIOS should not even request these from us now that we
aren't claiming we support these, but when it does anyway, don't pretend it
succeeded. It should be the right thing to do, but might confuse the BIOS.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 12 Apr 2013 12:18:37 +0000 (15:18 +0300)]
drm/i915: protect backlight registers and data with a spinlock
Backlight data and registers are fiddled through LVDS/eDP modeset
enable/disable hooks, backlight sysfs files, asle interrupts, and register
save/restore. Protect the backlight related registers and driver private
fields using a spinlock.
The locking in register save/restore covers a little more than is strictly
necessary, including non-modeset case, for simplicity.
v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code
paths leading there.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Jani Nikula [Fri, 12 Apr 2013 12:18:36 +0000 (15:18 +0300)]
drm/i915: keep max backlight internal to intel_panel.c
In preparation of adding locking to backlight, make max backlight value
(the modulation frequency the PWM duty cycle value must not exceed)
internal to intel_panel.c.
Have intel_panel_set_backlight() accept a caller defined range for level,
and scale input to max backlight value internally.
Clean up intel_panel_get_max_backlight() and usage internally.
Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Fri, 19 Apr 2013 09:24:34 +0000 (11:24 +0200)]
drm/i915: Disable high-bpc on pre-1.4 EDID screens
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>
Daniel Vetter [Wed, 24 Apr 2013 09:13:35 +0000 (11:13 +0200)]
drm/i915: disable interrupts earlier in the driver unload code
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>
Ville noticed this while doing another review; we may as well cancel
this work just to make sure we don't try anything fancy after disabling
the RPS interfaces.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: make sure GPU freq drops to minimum after entering RC6 v4
On VLV, the Punit doesn't automatically drop the GPU to it's minimum
voltage level when entering RC6, so we arm a timer to do it for us from
the RPS interrupt handler. It'll generally only fire when we go idle
(or if for some reason there's a long delay between RPS interrupts), but
won't be re-armed again until the next RPS event, so shouldn't affect
power consumption after we go idle and it triggers.
v2: use delayed work instead of timer + work queue combo (Ville)
v3: fix up delayed work cancel (must be outside lock) (Daniel)
fix up delayed work handling func for delayed work (Jesse)
v4: cancel delayed work before RPS shutdown (Jani)
pass delay not absolute time to mod_delayed_work (Jani)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's introduce one more of those orthogonal feature macros. This should
hopefully make the code more readable and make things easier for new platform
enabling.
This time, HAS_FPGA_DBG_UNCLAIMED() is true for platforms that have bit
31 of FPGA_DBG able to signal unclaimed writes.
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>
drm/i915: Only reprobe display on encoder which has received an HPD event (v2)
Instead of calling into the DRM helper layer to poll all connectors for
changes in connected displays probe only those connectors which have
received a hotplug event.
v2: Resolved conflicts with changes in previous commits.
Renamed function and and added a WARN_ON() to warn of
intel_hpd_irq_event() from being called without
mode_config.mutex held - suggested by Jani Nikula.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Add PTE encoding function to the gtt/ppgtt vtables.
Sandybridge/Ivybridge, Bay Trail, and Haswell all have slightly
different page table entry formats. Rather than polluting one function
with generation checks, simply use a function pointer and set up the
correct PTE encoding function at startup.
v2: Move the gen6_gtt_pte_t typedef to i915_drv.h so that the function
pointers and implementations have identical signatures. Also remove
inline keyword on gen6_pte_encode. Both suggested by Jani Nikula.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Tested-by: Daniel Leung <daniel.leung@linux.intel.com> [v1] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Thu, 18 Apr 2013 19:35:41 +0000 (16:35 -0300)]
drm/i915: use cpu_transcoder for TRANS_DDI_FUNC_CTL
... 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 88adfff1ad5019f65b9d0b4e1a4ac900fb065183
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>
Paulo Zanoni [Thu, 18 Apr 2013 19:35:40 +0000 (16:35 -0300)]
drm/i915: check the power well inside haswell_get_pipe_config
This fixes "unclaimed register" messages when booting with eDP only
and i915.disable_power_well=1.
The error messages were caused by:
commit 0e8ffe1bf81b0780cc6229cb38664754dffe8776
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>
Paulo Zanoni [Fri, 12 Apr 2013 20:57:58 +0000 (17:57 -0300)]
drm/i915: print Gen5+ CPU/PCH poison interrupts
This is bad news and shouldn't be happening.
V2: 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>
Paulo Zanoni [Fri, 12 Apr 2013 20:57:57 +0000 (17:57 -0300)]
drm/i915: report Gen5+ CPU and PCH FIFO underruns
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>
Daniel Vetter [Thu, 18 Apr 2013 19:10:43 +0000 (21:10 +0200)]
drm/i915: fix VLV limits
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>
Uses slightly different interfaces than other platforms.
v2: track actual set freq, not requested (Rohit)
fix debug prints in init code (Jesse)
v3: don't write sleep reg (Jesse)
re-add RC6 wake limit write (Ben)
fixup thresholds to match other platforms (Ben)
clean up mem freq calculation (Ben)
clean up debug prints (Ben)
v4: move defines from punit patch (Ville)
v5: remove writes to nonexistent regs (Jesse)
put RP and RC regs together (Jesse)
fix RC6 enable (Jesse)
v6: use correct fuse reads from NC (Jesse)
split out min/max funcs for use in sysfs (Jesse)
add debugfs & sysfs freq controls (Jesse)
v7: update with Ben's hw_max changes (Jesse)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v6)
[danvet: Follow checkpatch sugggestion to use min_t to avoid casting
fun.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When requesting frequency changes or querying status from the Punit, we
need to use an opcode that corresponds to the frequency, taking into
account the memory frequency.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Wed, 17 Apr 2013 14:48:50 +0000 (17:48 +0300)]
drm/i915: Use alphabetical names for transcoders too
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>
Daniel Vetter [Thu, 11 Apr 2013 17:49:07 +0000 (19:49 +0200)]
drm/i915: move debug output back to the right place
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>
Daniel Vetter [Thu, 11 Apr 2013 14:29:10 +0000 (16:29 +0200)]
drm/i915: add i9xx pfit pipe asserts
We can only enable the pfit if the pipe is disabled. Ensure that this
is obeyed with a neat assert.
Also check whether the pfit is off before enabling it - if not we've
lost track of things somewhere since the pfit is only ever used by the
lvds output.
v2: Fix spell fail in the commit message pointed out by Ville&Jani.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel Vetter [Wed, 17 Apr 2013 18:15:07 +0000 (20:15 +0200)]
drm/i915: move cpu_transcoder to the pipe configuration
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>
Paulo Zanoni [Mon, 8 Apr 2013 18:48:08 +0000 (15:48 -0300)]
drm/i915: preserve the PBC bits of TRANS_CHICKEN2
Bits 30 and 24:0 are PBC, so don't zero them. Some of the other bits
are being zeroed, but I couldn't find a reason for this, so leave them
as they are for now to avoid regressions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Delete the redudant #define that Imre spotted in his review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4)
We disable hoptplug detection when we encounter a hotplug event
storm. Still hotplug detection is required on some outputs (like
Display Port). The interrupt storm may be only temporary (on certain
Dell Laptops for instance it happens at certain charging states of
the system). Thus we enable it after a certain grace period (2 minutes).
Should the interrupt storm persist it will be detected immediately
and it will be disabled again.
v2: Reordered drm_i915_private: moved hotplug_reenable_timer to hpd state tracker.
v3: Clarified loop start value,
Removed superfluous test for Ivybridge and Haswell,
Restructured loop to avoid deep nesting (all suggested by Ville Syrjälä)
v4: Fixed two bugs pointed out by Jani Nikula.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3)
This patch disables hotplug interrupts if an 'interrupt storm'
has been detected.
Noise on the interrupt line renders the hotplug interrupt useless:
each hotplug event causes the devices to be rescanned which will
will only increase the system load.
Thus disable the hotplug interrupts and fall back to periodic
device polling.
v2: Fixed cleanup typo.
v3: Fixed format issues, clarified a variable name,
changed pr_warn() to DRM_INFO() as suggested by
Jani Nikula <jani.nikula@linux.intel.com>.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When an encoder is shared on several connectors there is only
one hotplug line, thus this line needs to be shared among these
connectors.
If HPD detect only works reliably on a subset of those connectors,
we want to poll the others. Thus we need to make sure that storm
detection doesn't mess up the settings for those connectors.
Therefore we store the settings in the intel_connector struct and
restore them from there.
If nothing is set but the encoder has a hpd_pin set we assume this
connector is hotplug capable.
On init/reset we make sure the polled state of the connectors
is (re)set to the default value, the HPD interrupts are marked
enabled.
Signed-off-by: Egbert Eich <eich@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
fires more than 5 times / sec).
Rationale:
Despite of the many attempts to fix the problem with noisy hotplug
interrupt lines we are still seeing systems which have issues:
Once cause of noise seems to be bad routing of the hotplug line
on the board: cross talk from other signals seems to cause erronous
hotplug interrupts. This has been documented as an erratum for the
the i945GM chipset and thus hotplug support was disabled for this
chipset model but others seem to have this problem, too.
We have seen this issue on a G35 motherboard for example:
Even different motherboards of the same model seem to behave
differently: while some only see only around 10-100 interrupts/s
others seem to see 5k or more.
We've also observed a dependency on the selected video mode.
Also on certain laptops interrupt noise seems to occur duing
battery charging when the battery is at a certain charge levels.
Thus we add a simple algorithm here that detects an 'interrupt storm'
condition.
v2: Fixed comment.
v3: Reordered drm_i915_private: moved hpd state tracking to hotplug work stuff.
v4: Followed by Jesse Barnes to use a time_..() macro.
v5: Fixed coding style as suggested by Jani Nikula.
Signed-off-by: Egbert Eich <eich@suse.de> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Fri, 12 Apr 2013 21:16:53 +0000 (18:16 -0300)]
drm/i915: don't intel_crt_init on any ULT machines
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>
I don't have a VLV to test it with, Jesse, Ken, can one of you test?
Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Fri, 12 Apr 2013 18:10:13 +0000 (19:10 +0100)]
drm/i915: Scale ring, rather than ia, frequency on Haswell
Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.
v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
Daniel Vetter [Fri, 12 Apr 2013 16:48:43 +0000 (18:48 +0200)]
drm/i915: Fixup Oops in the pipe config computation
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
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
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>
Jani Nikula [Fri, 12 Apr 2013 12:18:38 +0000 (15:18 +0300)]
drm/i915: ensure single initialization and cleanup of backlight device
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>
Daniel Vetter [Thu, 11 Apr 2013 18:22:50 +0000 (20:22 +0200)]
drm/i915: don't check inconsistent modeset state when force-restoring
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>
Ville Syrjälä [Tue, 9 Apr 2013 10:02:47 +0000 (13:02 +0300)]
drm/i915: IVB/HSW have 32 fence register
Increase the number of fence registers to 32 on IVB/HSW. VLV however
only has 16 fence registers according to the docs.
Increasing the number of fences was attempted before [1], but there was
some uncertainty about the maximum CPU fence number for FBC. Since then
BSpec has been updated to state that there are in fact 32 fence registers,
and the CPU fence number field in the SNB_DPFC_CTL_SA register is 5 bits,
and the CPU fence number field in the ILK_DPFC_CONTROL register must be
zero. So now it all makes sense.
changed the sysfs read semantics for 'gt_max_freq_mhz'. By
always returning overclock max instead of stored value.
Fix this by returning the stored value. Separate sysfs entry
should be considered for overclocking max freq.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63415 Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:42 +0000 (15:13 +0300)]
drm/i915: Configure GAM_ECOCHK appropriatly for Gen7
IVB and HSW use different encodings for the PPGTT cacheability bits in
the GAM_ECOCHK register.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:41 +0000 (15:13 +0300)]
drm/i915: Set GAC_ECO_BITS register on Gen7+
According to BSpec GAC_ECO_BITS register exists on Gen7 platforms as
well. Configure it accordingly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ville Syrjälä [Thu, 4 Apr 2013 12:13:40 +0000 (15:13 +0300)]
drm/i915: Add ECOBITS_SNB_BIT
GAC_ECO_BITS has a bit similar to GAM_ECOCHK's ECOCHK_SNB_BIT. Add
the define, and enable it on SNB.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 5 Apr 2013 21:29:23 +0000 (14:29 -0700)]
drm/i915: Don't default to overclock max
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Ben Widawsky [Fri, 5 Apr 2013 21:29:22 +0000 (14:29 -0700)]
drm/i915: Better overclock support
Most importantly this will allow users to set overclock frequencies in
sysfs. Previously the max was limited by the RP0 max as opposed to the
overclock max. This is useful if one wants to either limit the max
overclock frequency, or set the minimum frequency to be in the overclock
range. It also fixes an issue where if one sets the max frequency to be
below the overclock max, they wouldn't be able to set back the proper
overclock max.
In addition I've added a couple of other bits:
Show the overclock freq. as max in sysfs
Print the overclock max in debugfs.
Print a warning if the user sets the min frequency to be in the
overclock range.
In this patch I've decided to store the hw_max when we read it from the
pcode at init. The reason I do this is the pcode reads can fail, and are
slow.
v2: Report when user requested overclocked max (Daniel)
Remove when user sets min to overclock range (Daniel)
Reported-by: freezer from #intel-gfx on irc Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Fixup the s/100MHz/50MHz/ confusion in an unrelated comment
that Mika spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / linux-beck.git / log