Broxton also has dmc to manage low-power display engine state.
Path of the firmware added in intel_csr.c.
Naming convention followed as <platform>_dmc_<api-version>.bin
v1: Initial version.
v2: Commit description added based on review comment from Sunil.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Clearing the watermarks for all pipes/planes when updating the
watermarks for a single CRTC change seems like the wrong thing to
do here. As is, this code will ony update any pipe/plane watermarks
that need updating and leave the remaining set to zero. Later, the
watermark checks in check_wm_state() will flag these zero'd out pipe/plane
watermarks and throw errors.
By clearing only the watermark values associated with the specific crtc
the other watermark values may remain unchanged.
v2: Make sure all the dirty flags are cleared. Damien
Clear all values assoicated with crtc/pipe being updated. Damien
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't want random people to touch these.
Especially true since we've just screwed up SKL by holding it way too
long under the preliminary flag because of some ABI issues. And now
there's howtos all over the internets about how to set this. Same
pretty much for anything else.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: drop fastboot changes, that option is gone.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.
vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL port E handling was added in
commit 26951caf55
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date: Mon Aug 17 15:55:50 2015 +0800
drm/i915/skl: enable DDI-E hotplug
but the whole function was moved in a another branch in
commit b93433ccf6
Author: Jani Nikula <jani.nikula@intel.com>
Date: Thu Aug 20 10:47:36 2015 +0300
drm/i915: move ibx_digital_port_connected to intel_dp.c
and the addition was lost at some backmerge that I was unable to
identify. Put it back in.
Tested-by: Tomi Sarvela <tomix.p.sarvela@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Not the first time! not the last time?
There is a possibility to use gcc 5's -Wbool-compare to try and compare
(reg) in those macros to a constant and gcc will warn that the
comparison between a boolean expression and a constant is always either
true or false. Maybe.
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We allocate memory for LVDS modes while parsing the VBT at startup, but
never free this memory when the driver is unloaded, causing a small
leak.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Use the new debug info in the intel_crtc struct in these functions
rather than passing them as args.
v2: move min/max assignment back above first trace call (Ville)
use scanline from crtc->debug rather than fetching a new one (Ville)
v3: fix up trace_i915_pipe_update_end, needs end scanline (Ville)
Requested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I used these additional fields to track down the issue I saw on HSW.
v2: move debug fields into a substruct (Ville)
v3: clean up debug code more (Ville)
References: https://bugs.freedesktop.org/show_bug.cgi?id=91579
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Fix the following 'make htmldocs' warnings:
.//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vma'
.//drivers/gpu/drm/i915/i915_gem.c:1729: warning: No description found for parameter 'vmf'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'old'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'new'
.//drivers/gpu/drm/i915/i915_gem.c:4962: warning: No description found for parameter 'frontbuffer_bits'
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Shared frontbuffer bits are causing warnings when same FB is displayed
in another plane without clearing the bits from previous plane.
v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel)
Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
[danvet: Drop INTEL_FRONTBUFFER_SPRITE_MASK since unused.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This stolen reserved stuff was introduced on g4x, so no need to waste
stolen on older platforms. Unfortunately configdb is no more so I can't
look up the right way to detect this stuff. I do have one hint as to
where the register might be on ctg, but I don't have a ctg to test it,
and on the elk I have here it doesn't contain sensible looking data.
For ilk grits suggegsts it might be in the same place as on snb (the
original PCI reg, not the mirror) but I can't be entirely sure about it
The register shows a round zero on my ilk.
So when there's no really good data for any of these platforms leave the
current "assume 1MiB" approach in place.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch fix following warnings while "make xmldocs".
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: No description
found for parameter 'req'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
parameter 'request' description in 'intel_logical_ring_begin'
.//drivers/gpu/drm/i915/intel_lrc.c:780: warning: Excess function
parameter 'ctx' description in 'intel_logical_ring_begin'
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extend init/init_hw split to context init.
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality &
alloc/init split.
This patch is intended to split out the allocation of resources &
initialisation to allow easier reuse of code for resume/gpu reset.
v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
Left ->init_context int intel_lr_context_deferred_alloc
(Daniel Vetter)
Remove unnecessary init flag & ring type test. (Daniel Vetter)
Improve commit message (Daniel Vetter)
v3: On init/reinit, set the hw next sequence number to the sw next
sequence number. This is set to 1 at driver load time. This prevents
the seqno being reset on reinit (Chris Wilson)
v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
on reset.
This makes it obvious which bbs are which after a reset. (David Gordon
& John Harrison)
Rebase.
v5: Rebase. Fixed rebase breakage. Put context pinning in separate
function. Removed code churn. (Thomas Daniel)
v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
Issue: VIZ-4798
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This avoids some bad register writes and generally feels more correct
than unconditionally trying to redirect interrupts and such.
References: https://bugs.freedesktop.org/show_bug.cgi?id=91777
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use WARN_ONCE in a bunch of places and demote a message that would
continually spam us.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Using intel_encoder's hpd_pin to check the live status
because of BXT A0/A1 WA for HPD pins and hpd_pin contains the
updated pin for the corresponding port.
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When WaEnableForceRestoreInCtxtDescForVCS is required, it is only
safe to send new contexts if the last reported event is "active to
idle". Otherwise the same context can fully preempt itself because
lite-restore is disabled.
Testcase: igt/gem_concurrent_blit
Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also check for correct revision id in each Gen9 platform (SKL until B0
and BXT until A0).
Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Tested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is done as a separate commit, to make it easier to revert
when things break.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of doing a hack during primary plane commit the state
is updated during atomic evasion. It handles differences in
pipe size and the panel fitter.
This is continuing on top of Daniel's work to make faster
modesets atomic, and not yet enabled by default.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet:
- simplify/future-proof if ladder that Jesse spotted
- resolve conflict in pipe_config_check and don't spuriously move the
code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The initial state is read out correctly and the state is atomic,
so it's safe to preserve the fb without any hacks if it's suitable.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It should really use the atomic state.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This might not have been set during boot, and when we preserve
the initial mode this can result in a black screen.
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Comment disagrees with the code which has changed a lot since
it was documented.
Note that the logic to remove -EIO handling was dropped in
commit 1488fc08c1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Apr 24 15:47:31 2012 +0100
drm/i915: Remove the deferred-free list
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In async mode crtc->config can be updated after the locks are released,
resulting in the wrong state being duplicated.
Note that this also removes a spurious assignment of crtc_state->crtc
introduced in
commit f0c60574eb
Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Date: Tue Apr 21 17:12:58 2015 +0300
drm/i915: Call drm helpers when duplicating crtc and plane states
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the conversion to atomic this cannot happen any more.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Unfortunately fbc still depends on legacy primary state, so
it can't be killed off completely yet.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function was still using the legacy state, convert it to atomic.
While we're at it, fix the FIXME too and disable the primary plane.
v2 (Daniel):
- Add FIXME explaining that update_primary_planes should soon get
removed anyway.
- Don't call ->disable_plane since we can't disable the primary plane
with a CS flip (noticed by Ville).
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Legacy state might not be updated any more.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fall back to VBT based backlight modulation frequency if it's not
set. Do not hard code.
This could be a problem if there is no VBT.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.
The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.
v2: Fix SPT and VLV. Thanks to Clint for the VLV code.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently the difference between backlight control on HSW vs. BDW/SKL is
that on HSW we modify the duty cycle on the CPU register, and have the
hardware pass the changes on to the PCH registers. We still drive the
PCH PWM on both. While HSW and BDW use the same LPT PCH, BDW does not
pass these messages on to the PCH. Therefore on BDW we need to enable
the PCH override bit, and program the PCH directly. (On SPT PCH, this
mode is the default.) We could as well do this on HSW too, and in fact
I've been told this is what a certain other operating system does. So
use PCH backlight override on HSW too.
This simplifies some follow-up code, but it does have the danger of
breaking backlight on HSW machines. It should work, but mysterious are
the ways of backlight.
While at it, name the related backlight hooks according to the PCH
rather than the CPU for clarity.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add stepping check for A0 workarounds, and remove the associated
FIXME tags.
Split out unrelated WAs for later condition checking.
v2: Fixed format (PeterL)
v3: Corrected stepping check for WaDisableSDEUnitClockGating
- Ignoring comment, following hardware spec instead. (ChrisH)
Added description for TILECTL setting (JonB)
Cc: Peter Lawthers <peter.lawthers@intel.com>
Cc: Chris Harris <chris.harris@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes regression from
commit f1afe24f0e
Author: Arun Siluvery <arun.siluvery@linux.intel.com>
Date: Tue Aug 4 16:22:20 2015 +0100
drm/i915: Change SRM, LRM instructions to use correct length
which forgot to account for the length bias when declaring the fixed
length.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91844
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The pfit state is stored as register values, so dump them as hex instead
of decimal to make some sense of the error messages.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These registers exist only before GEN5, so currently we may access
undefined registers on VLV/CHV and BXT. Apply the workaround only pre
GEN5.
Since the workaround is relevant only when LVDS is present, for clarity
apply it only if this is the case.
This triggered an unclaimed register access warning on BXT.
v2: (Ville)
- move the workaround to the LVDS init code
- print a debug note about the workaround
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This register exists only pre GEN5, but atm we also access it on
VLV/BXT/CHV. Prevent accessing it on these latter platforms.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A small, very small, step to sharing the duplicate code between
execlists and legacy submission engines, starting with the ringbuffer
allocation code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
TPS3 is mandatory for downstream devices that support HBR2, and Intel
platforms that support HBR2 also support TPS3. Whenever TPS3 is
supported by both the source and sink, it should be used. In other
words, whenever the source and sink are capable of 5.4 Gbps link, we
should anyway go for TPS3, regardless of the link rate being selected.
Log an error if the sink has advertized HBR2 capability without TPS3
capability.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
