Suppressing LCPLL disabling was added to avoid interfering with the DMC
firmware. It is not needed any more since we uninit CDCLK now with the
DMC deactivated (DC states disabled). We also must disable it during system
suspend as part of the Bspec "Display uninit sequence".
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-10-git-send-email-imre.deak@intel.com
We need to disable the DC states during display core init to sanitize
the HW state we inherit from the BIOS. We need to disable it during
display core uninit too, since the power well framework will leave it
enabled (since we get to the display core uninit step with all power
domains disabled already).
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-9-git-send-email-imre.deak@intel.com
With the DMC firmware installed we don't need to handle HW resources
that are handled automatically by the firmware. Besides being redundant
this can also interfere with the firmware, possibly getting it into a
broken/blocked state. The on-demand handling of PW1 was already half-way
removed, MISC IO was still handled in this way. After the last patch we
init/uninit these HW resources manually as part of the display core
init/uninit sequence, so we can now remove the on-demand handling for
these completely.
We still keep around the power wells (with no domains attached to them)
since the manual toggling during display core init/uninit happens via
the current API.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
[s/beeing/being/ in commit message (imre)]
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-7-git-send-email-imre.deak@intel.com
We need to initialize the display core part early, before initializing
the rest of the display power state. This is also described in the bspec
termed "Display initialization sequence". Atm we run this sequence
during driver loading after power domain HW state initialization which
is too late and during runtime suspend/resume which is unneeded and can
interere with DMC functionality which handles HW resources toggled
by this init/uninit sequence automatically. The init sequence must be
run as the first step of HW power state initialization and during
system resume. The uninit sequence must be run during system suspend.
To address the above move the init sequence to the initial HW power
state setup and the uninit sequence to a new power domains suspend
function called during system suspend.
As part of the init sequence we also have to reprogram the DMC firmware
as it's lost across a system suspend/resume cycle.
After this change CD clock initialization during driver loading will
happen only later after other dependent HW/SW parts are initialized,
while during system resume it will get initialized as the last step of
the init sequence. This distinction can be removed by some refactoring
of platform independent parts. I left this refactoring out from this
series since I didn't want to change non-SKL parts. This is a TODO for
later.
v2:
- fix error path in i915_drm_suspend_late()
- don't try to re-program the DMC firmware if it failed to load
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447774433-20834-1-git-send-email-imre.deak@intel.com
Before this patch, we used the intel_display_power_{get,put} functions
to make sure the PW1 and Misc I/O power wells were enabled all the
time while LCPLL was enabled. We called a get() at
intel_ddi_pll_init() when we discovered that LCPLL was enabled, then
we would call put/get at skl_{un,}init_cdclk().
The problem is that skl_uninit_cdclk() is indirectly called by
intel_runtime_suspend(). So it will only release its power well
_after_ we already decided to runtime suspend. But since we only
decide to runtime suspend after all power wells and refcounts are
released, that basically means we will never decide to runtime
suspend.
So what this patch does to fix that problem is move the PW1 + Misc I/O
power well handling out of the runtime PM mechanism: instead of
calling intel_display_power_{get_put} - functions that touch the
refcount -, we'll call the low level intel_power_well_{en,dis}able,
which don't change the refcount. This way, it is now possible for the
refcount to actually reach zero, and we'll now start runtime
suspending/resuming.
v2 (from Paulo):
- Write a commit message since the original patch left it empty.
- Rebase after the intel_power_well_{en,dis}able rename.
- Use lookup_power_well() instead of hardcoded indexes.
Testcase: igt/pm_rpm/rte (and every other rpm test)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92211
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92605
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com
The current lookup code wouldn't find a power well if it's not in any
power domain. There wasn't any power wells before but an upcoming patch
will detach the power domains from power well#1 and the MISC IO power
wells, so fix things up accordingly.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-3-git-send-email-imre.deak@intel.com
lookup_power_well() expects uniq power well IDs, but atm we have
uninitialized IDs which would clash with those power wells with a 0
ID. This wasn't a problem so far since nothing looked up such a power
well, but an upcoming patch will (Misc IO for SKL), so fix this up on
platforms where this matters.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-2-git-send-email-imre.deak@intel.com
After fixing the same issue in the set_caching IOCTL and Chris' request
to check out the possibilities for an improved RPM ref handling I
noticed that we have the same issue in the set_tiling IOCTL. Fix this
up.I didn't see any bug reports about this one, but the GTT unbind
operation on this path accesses the HW, which needs the ref.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447092986-11165-1-git-send-email-imre.deak@intel.com
When accessing through the GTT from one CPU whilst concurrently updating
the GGTT PTEs in another thread, the hardware likes to return random
data. As we have strong serialisation prevent us from modifying the PTE
of an active GTT mmapping, we have to conclude that it whilst modifying
other PTE's that error occurs. (I have not looked for any pattern such
as modifying PTE within the same page or cacheline as active PTE -
though checking whether revoking neighbouring objects should be enough
to test that theory.) The corruption also seems restricted to Braswell
and disappears with maxcpus=0. This patch stops all access through the
GTT by other CPUs when we update any PTE by stopping the machine around
the GGTT update.
Note that splitting up the 64 bit write into two 32 bit writes was
tried and found to fail too.
Testcase: igt/gem_concurrent_blit
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89079
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about 2x 32bits failing too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Compliance test 4.3.1.11 requires source to perform link training
always if the automated test requests for it. This patch
enforces this requirement.
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Automated test data that is updated when a test is requested is not cleared
till next automated test request is recevied which can cause various
problems. This patch fixes this by clearing this during the next
short pulse and on hot unplug.
For example, when TEST_LINK_TRAINING is requested it is updated
to appropriate variable inside intel_dp_handle_test_request
but is also cleared only inside the same function. if the next
short pulse does not have the AUTOMATED_TEST_REQUEST bits set
the variable will not be cleared resulting in carrying incorrect
test status in local variables.
v2: Added comments and moved nack and defer variables before set_edid
(Sonika)
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If ddb allocation for planes in current CRTC is changed, that doesn't
lead to ddb allocation change for other CRTCs, because our DDB allocation
is not dynamic according to plane parameters, ddb is allocated according
to number of CRTC enabled, & divided equally among CTRC's.
In current condition check during Watermark calculation, if number of
plane/ddb allocation changes for current CRTC, Watermark for other pipes
are recalculated. But there is no change in DDB allocation of other pipe
so watermark is also not changed, This leads to warning messages.
WARN_ON(!wm_changed)
This patch corrects this and check if DDB allocation for pipes is changed,
then only recalculate watermarks.
v2 (by Matt): Rebased to latest -nightly and fixed a typo
Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com>
Reviewed-by(v1): Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset
under dev_priv, like we for DSI and GPIO for example.
TODO: could probably move a bunch of this kind of stuff into the device
info instead...
v2: Drop the spurious whitespace change (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-7-git-send-email-ville.syrjala@linux.intel.com
Rather than computing on demand, store also the aux data reg
offsets under intel_dp.
v2: Duplicate some code to make things less magic (Jani)
v3: Use PORT_B registers for invalid ports in g4x_aux_data_reg()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-6-git-send-email-ville.syrjala@linux.intel.com
Currently we determine the location of the AUX registers in a confusing
way. First we assume the PCH registers are used always, but then we
override it for everything but HSW/BDW to use DP+0x10. Very confusing.
Let's just make it straightforward and simply add a few functions to
pick the right AUX_CTL based on the DP port.
To deal with VLV/CHV we'll include the display_mmio_offset into the
AUX register defines.
v2: Reorder patches (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-5-git-send-email-ville.syrjala@linux.intel.com
v2: Keep some MISSING_CASE() stuff (Jani)
s/-1/-PIPE_B/ in the register macro
Fix typo in patch subject
v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani)
v4: Reorder patches (Chris)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v3)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3)
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-4-git-send-email-ville.syrjala@linux.intel.com
Use kasprintf() to generate the "DPDDC-<port>" name for the aux helper.
To deal with errors properly make intel_dp_aux_init() return something,
and adjust the caller to match. It seems we were also missing a
intel_dp_mst_encoder_cleanup() call on edp (non-port A) init failures,
so add that too.
The whole error/cleanup ordering doesn't feel entirely sane to me, but
I'll leave that part alone for now.
v2: Use kasprintf() instead of a table, reorder patches (Chis)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
While comparing the B-Spec with the code I noticed that several
values in these tables have been updated in the spec, so I
changed the code to match..
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jim Bride <jim.bride@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com
The i_boost level in the DDI translation tables are stored per level.
However, skl_ddi_set_iboos() would choose an entry of that table based
on the port argument.
Cc: Jim Bride <jim.bride@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447247754-802-1-git-send-email-ander.conselvan.de.oliveira@intel.com
As during disabling dc6 no need to check for csr firmware
loading status, so removed the assert call (Requested by Damien).
Cc: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-14-git-send-email-imre.deak@intel.com
Currently during system s/r we enable/disable DC6, so before we do so
make sure that the firmware loading is complete.
Note that whether we need to enable DC6 for S3/S4 is still open. At
least the firmware program is lost during S3 and we need to reprogram it
after resuming. Until this is clarified we keep the current behavior and
enable/disable DC6.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-13-git-send-email-imre.deak@intel.com
During driver unload to ensure we dont have any pending task,
flush_work added to complete firmware loading task.
v1: Initial version.
v2: As per review comments from Daniel,
Removed flush_work from skl_set_power_well. As we have taken
power well refernece and rpm count during firmware loading
by using display_power_domain_get/put - this will always
ensure rpm will be blocked if firmware is not loaded.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-12-git-send-email-imre.deak@intel.com
Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
which is a notch more obvious what it does than having a special
completion.
The next patch will properly synchronize against the async loader in
the resume and unload code.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-11-git-send-email-imre.deak@intel.com
The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.
v2-v3:
- unchanged
v4:
- rebased on top of latest drm-intel-nightly
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: remove note about BE cast from commit message, it's not relevant
any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: fix checkpatch warn on multiple blank lines]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341089-2735-1-git-send-email-imre.deak@intel.com
As all csr firmware related opertion are not using any
any data structures of drm framework level, so better to
use dev_priv instead of dev. it's a new style! :)
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-9-git-send-email-imre.deak@intel.com
We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-8-git-send-email-imre.deak@intel.com
If we really want to we can be more verbose here, but we really don't
need an entire function for this.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-7-git-send-email-imre.deak@intel.com
Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.
Apply this across the entire file since it was sticking out a bit too
much.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from the commit message, it's
not relevant any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-6-git-send-email-imre.deak@intel.com
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_program.
Instead ordering should be ensured with the generic
wait_for_completion()/complete(). Or more specific functions
provided by the core kernel like e.g.
flush_work()/cancel_work_sync() in the case of synchronizing with a
work item.
- Don't invent own completion like the following code did with the
(already removed) wait_for(csr_load_status_get()) pattern - it's
really hard to get these right when you want them to be _really_
correct (and be fast) in all cases. Furthermore it's easier to read
code using the well-known primitives than new ones using
non-standard names.
Before enabling/disabling DC6 check if the firmware is loaded
successfully. This is guaranteed during runtime s/r, since otherwise we
don't enable RPM, but not during system s/r.
Note that it's still unclear whether we need to enable/disable DC6
during system s/r, until that's clarified, keep the current behavior and
enable/disable DC6.
Also after this patch there is a race during system s/r where the
firmware may not be loaded yet, that's addressed in an upcoming patch.
v2-v3:
- unchanged
v4:
- rebased on latest drm-intel-nightly
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: added code and note about checking if the firmware loaded ok,
before enabling/disabling it]
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447341037-2623-1-git-send-email-imre.deak@intel.com
Avoids non-static functions since all the callers are in intel_rpm.c.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: removed note about reg definitions from commit message, since
it's not relevant any more]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
[Jani: make assert_csr_loaded static]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-4-git-send-email-imre.deak@intel.com
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).
Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit too
much, but since the firmware loading task should completely fairly
quickly this won't be a real problem really.
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-3-git-send-email-imre.deak@intel.com
Skl is fully dependent on dmc for going to low power state (dc5/dc6).
This requires a trigger from rpm. To ensure the dmc firmware
is available for runtime pm support rpm-reference-count is used
by not releasing the rpm reference if firmware loading is
not completed.
So moved the intel_csr_ucode_init call after runtime pm enable.
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
[imre: moved the call right after power domain init to avoid race with
the console modesetting]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446069547-24760-2-git-send-email-imre.deak@intel.com
Have only one if ladder for platforms and only one range check for
size. Makes it easier to handle new platforms. Remove the use of
negative return values in char, which might underflow to be positive for
some negative error codes.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445344713-1407-3-git-send-email-jani.nikula@intel.com
No need to verify VMA belongs to GGTT since:
1. The function must return a normal VMA belonging to passed in VM.
2. There can only be one normal VMA for any VM.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447329595-17495-1-git-send-email-tvrtko.ursulin@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Minor fixup to d0669d0075 ("drm/i915: Clean up LVDS register
handling") which intended to read lvds_reg just once at the
beginning of intel_lvds_init() and use that throughout the rest
of the function but accidentally missed one register readout.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20151107141244.AB7616E242@gabe.freedesktop.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reading the driver load/unload code leaves one confused as there's
an async_schedule() in the load, but not async_synchronize_full()
in sight. In fact it's hidden inside intel_fbdev.c. So let's move the
async_schedule() into intel_fbdev.c as well so that it's next to the
async_synchronize_full(), which should make the relationship easier
to see.
Plus this way we won't schedule a nop function call when fbdev is
disabled. And we were passing a pointer to a static inline
function to async_schedule(), which seems rather dubious to me.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
We set up fbdev last during load, so doing the fbdev cleanup should be
first.
We weren't supposed to drop the init power during driver unload, but since
the fbdev teardown happened after intel_power_domains_fini() that could
have happened due in one of two ways. First it could have happened
during the modeset caused by normal fbdev cleanup. But in addition it
could have happened already via the intel_fbdev_initial_config() since
that is executed asynhronously, and the async_synchronize_full() was
done during fbdev cleanup, after intel_power_domains_fini(). All of
that got eliminated by
commit 292b990e86 ("drm/i915: Update power domains on readout.")
since we now drop the init power synchronously during driver load.
So there is no real bug wrt. the init power anymore, but still it seems
better to do the fbdev cleanup first, before we've potentially cleaned
up something else important.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
intel_runtime_pm_disable() takes an extra rpm reference which combined
with the one we leak from intel_display_set_init_power() leaves the
usage count at <original>+1 after the driver has been unloaded.
The original ref is dropped explicitly in intel_runtime_pm_enable().
So the next time we load the driver we can no longer do runtime PM ever.
This used to work, but
commit 292b990e86 ("drm/i915: Update power domains on readout.")
broke things by not dropping the init power domain during fbdev
teardown. Based on the comment in intel_power_domains_fini(), the
way it used to to work wasn't intentional. As in we weren't supposed
to drop the init power during driver unload. And since we no longer
do, we now leak an extra rpm reference.
So fix things by throwing intel_runtime_pm_disable() to the bin, so
that the only leaked reference comes from the init power domain.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Stone <daniels@collabora.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Fixes: 292b990e86 ("drm/i915: Update power domains on readout.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446815313-9490-2-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
ironlake_set_pll_cpu_edp() only gets called just before
ironlake_edp_pll_on(), so just pull the code into ironlake_edp_pll_on().
Also toss in a debug print into ironlake_edp_pll_off() to match the one
we have in ironlake_edp_pll_on().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-15-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Use intel_dp->DP in the eDP PLL setup, instead of doing RMWs.
To do this we need to move DP_AUDIO_OUTPUT_ENABLE setup to happen later,
so that we don't enable audio accidentally while configuring the PLL.
Note that actually we already enabled audio before the port due to
the double port register write magic required by VLV/CHV from
7b713f50d7 ("drm/i915: Fix eDP link training when switching pipes on VLV/CHV")
So that gets changed now to keep audio off as long as the port is off.
Also intel_dp_link_down() must be made to update intel_dp->DP so that we
don't re-enable the port by accident when turning off the PLL. This is
safe now that we don't call intel_dp_link_down() during link retraining.
v2: Add a note about the audio vs. port enable (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1447164977-32315-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
We get underruns on the other pipe when enabling the CPU eDP PLL and
port on ILK.
Bspec knows about the PLL issue, and recommends doing a vblank wait just
prior to enabling the PLL. That does seem to help, but unfortunately we
get another underrun when actually enabling the CPU eDP port. Bspec
doesn't mention that at all, and the same vblank wait trick doesn't
appear to be effective there.
Since I have no better clue how to deal with this, just hide the errors.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-10-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Doing the IBX transcoder B workaround causes underruns on
pipe/transcoder A. Just hide them by disabling underrun reporting for
pipe A around the workaround.
It might be possible to avoid the underruns by moving the workaround
to be applied only when enabling pipe A. But I was too lazy to try it
right now, and the current method has been proven to work, so didn't
want to change it too hastily.
Note that this can re-enable underrun reporting on pipe A if was
already disabled due to a previous actual underrun. But that's OK, we
may just get a second underrun report if another real underron occurrs
on pipe A.
v2: Note that pipe A underruns can get re-enabled due to this (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225802-11180-1-git-send-email-ville.syrjala@linux.intel.com
ironlake_enaable_pch_transcoder() checks for CPT to see if it should
enable the timing override chicken bit, but
ironlake_disable_pch_transcoder() checks for !IBX to see if it should
clear the same bit. Change ironlake_disable_pch_transcoder() to check
for CPT as well to keep the two sides consistent.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-8-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not
always get an interrupt on a FIFO underrun. But we can always do an
explicit check (like we do on GMCH platforms that have no underrun
interrupt).
v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for
all the relevant underrun bits, so in order to keep the error interrupt
enabled, we need to have underrun reporting enabled on all PCH
transocders. Currently we leave the underrun reporting disabled when
the pipe is off, which means we won't get any underrun interrupts
when only a subset of the pipes are active.
Fix the problem by re-enabling the underrun reporting after the pipe has
been disabled. And to avoid the spurious underruns during pipe enable,
disable the underrun reporting before embarking on the pipe enable
sequence. So this way we have the error reporting disabled while
running through the modeset sequence.
v2: Re-enable PCH FIFO underrun reporting unconditionally on pre-HSW
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225691-10928-1-git-send-email-ville.syrjala@linux.intel.com
As we did for ILK/SNB/IVB, move the PCH FIFO underrun enable to happen
after the encoder enable on HSW+. And again, for symmetry, move the
the disable to happen before encoder disable.
I've left out the vblank wait before the enable here because I don't
know if it's needed or not. Actually I don't know if this entire
change is needed as I don't have a HSW/BDW with VGA output.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
We get spurious PCH FIFO underruns if we enable the reporting too soon
after enabling the crtc. Move it to be the last step, after the encoder
enable. Additionally we need an extra vblank wait, otherwise we still
get the underruns. Presumably the pipe/fdi isn't yet fully up and running
otherwise.
For symmetry, disable the PCH underrun reporting as the first thing,
just before encoder disable, when shutting down the crtc.
v2: Do the PCH underrun enable unconditionally (Jani, Daniel)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1446225627-10809-1-git-send-email-ville.syrjala@linux.intel.com
From our maintainer Daniel Vetter a few days ago:
"Oh dear this is dead code. kdbg uses the fbcon, which always uses
untiled, which means fbc will never be enabled. Also we have 0 users
and 0 test coverage for kdbg on top of i915 (Jesse implemented it
for fun years back). Imo just remove all this code."
Adding to what Daniel said: for kgdboc's KMS support,
intel_pipe_set_base_atomic() already manually disables FBC, so we
won't do the in_dbg_master() check there. This is essentially a revert
of:
commit c924b934d0
Author: Jason Wessel <jason.wessel@windriver.com>
Date: Thu Aug 5 09:22:32 2010 -0500
i915: when kgdb is active display compression should be off
Besides, it is not clear what is the exact problem caused by FBC, and
why other features such as PSR, DRRS, IPS and RPM are not also
checking for in_dbg_master(). IMHO we should either remove the code as
suggested by Daniel or we add some nice comments explaining why is FBC
so special.
v2: Rebase due to new patch order.
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-13-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Daniel was looking at this code and asked about whether fb->pitches[0]
is correct, then he suggested we should a comment to make sure it is
actually intentional.
For more information on the CFB size calculation, please see the
commit message of:
commit c4ffd40908
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Thu Oct 1 19:55:57 2015 -0300
drm/i915: fix CFB size calculation
Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-12-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
If we run igt/kms_frontbuffer_tracking, this message will appear
thousands of times, eating a significant part of our dmesg buffer.
It's part of the expected FBC behavior, so let's just silence it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-10-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the
call from intel_display.c. Currently we only have the "enabled"
software state, but later we'll have both "enabled" and "active", and
we'll add assertions to them, so just calling intel_fbc_disable() from
intel_modeset_init() won't work. It's better to make sure
intel_fbc_init() already puts the hardware in the expected state, so
we can put nice assertions in the other functions.
v2: Keep/improve the comment (Chris).
v3: Improve the commit message a little bit.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-9-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
If FBC is disabled we will still call intel_fbc_invalidate(), and as a
result we may call intel_fbc_deactivate(), which will try to touch
registers.
I'm pretty sure I saw this happen on a runtime suspended device, and
I'm almost sure I was running igt/pm_rpm. It produced the "you touched
registers while the device is suspended" WARNs. But this was some time
ago and I can't remember exactly which conditions were necessary to
reproduce the problem.
v2: Rebase to new series order.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-8-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Don't try to list in comments the cases where we should enable or
disable FBC: it varies a lot with the hardware generations and the
code should be the documentation. Also notice that there's already a
huge gap between the comments and what's in the code.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-7-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
This change was part of the commit that makes intel_fbc_update()
receive an intel_crtc as argument instead of dev_priv, but since it
was polluting the diff with too many chunks I decided to move it to
its own commit.
It seems that our developers are favoring having this instead of the
old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the
mentioned commit we'll get rid of the drm_crtc variable, so let's do
an intermediate commit with the rename, so on the next commit we'll
have just struct intel_crtc *crtc.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-6-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
We're going to kill intel_fbc_find_crtc(), that's why a big part of
the logic moved from intel_fbc_find_crtc() to crtc_is_valid().
v2:
- Rebase due to pipe_a_only change.
- Split the multiline conditional (Chris).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-5-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Although the term "nuke" is part of the FBC spec, it's not very
intuitive, so let's rename it to make it easier for people that are
not familiar with the spec.
Requested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
The bspec indicates that DDI A using four lanes is the only valid
configuration for Broxton (Broxton doesn't have a DDI E to split these
lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always
be set by the BIOS. However some BIOS versions seem to only be setting
this bit if eDP is actually lit up at boot time; if the BIOS doesn't
turn on the eDP panel because an external display is plugged in, then
this bit is never properly initialized. The end result of this is that
we wind up calculating a lower max data rate than we should and may wind
up rejecting the native mode for panels that we should be able to drive.
Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on
in our driver's internal state if we recognize that we're running on BXT
where it should have been on anyway.
Cc: Imre Deak <imre.deak@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Tested-by: Bob Paauwe <bob.j.paauwe@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446764012-27251-1-git-send-email-matthew.d.roper@intel.com
VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.
This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We have had one case where buggy csr/dmc firmware version influenced
gt side and caused a hang. Add dmc firmware loading state and
version to error state.
v2: - Rebased on top of Damien's patches
- included fw load state
v3: include dmc info only if platform supports it (Chris)
v4: move *csr to branch scope (Chris)
v5: remove dependency to csr_state
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446124879-22240-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.
v2: Move all CSR specific registers to i915_reg.h (Ville)
v3: Rebase
v4: Rebase (RPM ref)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220487-32691-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
For bxt CSR firmware exposes a count of dc5 entries. Expose
it through debugs
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The CSR firmware expose two counters, handy to check if we are indeed
entering DC5/DC6.
v2: Rebase
v3: Take RPM ref before reading (Imre)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220412-32574-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Create a new debufs file for it, we'll have a few more things to add
there.
v2: Fix checkpatch warning about static const array
v3: use named initializers (Ville)
v4: strip out csr_state as it will be removed in future (Ville, Imre)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-3-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.
As of now the current version included in distribution
firmware packages is very like to be 1.19. Play it safe and
refuse to load a firmware version that may affect gpu
side stability.
With < 1.23 there is a palette and dmc ram corruption issue
so blacklist anything below that.
v2: Refuse to load fw instead of notifying the user
v3: Rebase on header version changes
v4: Refuse to load anything less than 1.23
v5: Give enough information for user for finding correct fw (Chris)
v6: better url and formatting (Chris)
v7: move error log for each fail path (Mika)
bail out earlier in load path (Imre)
v8: Fix the version check (Imre)
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Arun Siluvery <arun.siluvery@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://01.org/linuxgraphics/downloads/skldmcver121
References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23
Testcase: igt/gem_exec_nop
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446220336-32392-1-git-send-email-mika.kuoppala@intel.com
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
That can be handy later on to tell which DMC firmware version the user
has, by just looking at the dmesg.
v2: use DRM_DEBUG_DRIVER (Chris)
v3: use DRM_INFO (Marc Herbert)
Cc: Marc Herbert <marc.herbert@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v1)
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445950025-5793-1-git-send-email-mika.kuoppala@intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Tested-by: Daniel Stone <daniels@collabora.com> # SKL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We had two failure modes here:
1.
Deadlock in intelfb_alloc failure path where it calls
drm_framebuffer_remove, which grabs the struct mutex and intelfb_create
(caller of intelfb_alloc) was already holding it.
2.
Deadlock in intelfb_create failure path where it calls
drm_framebuffer_unreference, which grabs the struct mutex and
intelfb_create was already holding it.
[Daniel Vetter on why struct_mutex needs to be locked in the second half
of intelfb_create: "The vma [for the fbdev] is pinned, the problem is
that we re-lookup it a few times, which is racy. We should instead track
the vma directly, but oh well we don't."]
v2:
* Reformat commit msg to 72 chars. (Lukas Wunner)
* Add third failure mode. (Lukas Wunner)
v5:
* Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message. (Jani Nicula)
v6:
* In intelfb_alloc, if __intel_framebuffer_create failed,
fb will be an ERR_PTR, thus not null. So in the failure
path we need to check for IS_ERR_OR_NULL to avoid calling
drm_framebuffer_remove on the ERR_PTR. (Lukas Wunner)
* Since this is init code a drm_framebuffer_unreference should
be all we need. drm_framebuffer_remove is for framebuffers
that userspace has created - and is getting somewhat
defeatured. (Daniel Vetter)
v7:
* Clarify why struct_mutex needs to be locked in the second half
of intelfb_create. (Daniel Vetter)
Fixes: 60a5ca015f ("drm/i915: Add locking around
framebuffer_references--")
Reported-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
[Lukas: Create v3 + v4 + v5 + v6 + v7 based on Tvrtko's v2]
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/47d4e88c91b3bf0f7a280cabec54c8c8cf0cf6f2.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In intelfb_alloc(), if the call to intel_pin_and_fence_fb_obj() fails,
the bo is unrefed twice: By drm_framebuffer_remove() and once more by
drm_gem_object_unreference(). Fix it.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/cd7b33330621a350b0159ec5e098297b139cfaf7.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Currently when allocating a framebuffer fails, the gem object gets
unrefed at the bottom of the call stack in __intel_framebuffer_create,
not where it gets refed, which is in intel_framebuffer_create_for_mode
(via i915_gem_alloc_object) and in intel_user_framebuffer_create
(via drm_gem_object_lookup).
This invites mistakes: __intel_framebuffer_create is also called from
intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref
was introduced there with a8bb681827 ("drm/i915: Fix error path leak
in fbdev fb allocation").
As suggested by Ville Syrjälä, fix the double unref and improve code
clarity by moving the unref away from __intel_framebuffer_create to
where the gem object gets refed.
Based on Tvrtko Ursulin's original v2.
v3: On fb alloc failure, unref gem object where it gets refed,
fix double unref in separate commit (Ville Syrjälä)
v4: Lock struct_mutex on unref (Chris Wilson)
v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC,
rephrase commit message (Jani Nicula)
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
[MBP 5,3 2009 nvidia MCP79 + G96 pre-retina]
Tested-by: Paul Hordiienko <pvt.gord@gmail.com>
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina]
Tested-by: William Brown <william@blackhats.net.au>
[MBP 8,2 2011 intel SNB + amd turks pre-retina]
Tested-by: Lukas Wunner <lukas@wunner.de>
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina]
Tested-by: Bruno Bierbaumer <bruno@bierbaumer.net>
[MBP 11,3 2013 intel HSW + nvidia GK107 retina]
Fixes: a8bb681827 ("drm/i915: Fix error path leak in fbdev fb
allocation")
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.de
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to prepare for a link training with DDI, the state machine
would call intel_ddi_prepare_link_retrain(). To remove the dependency to
the hardware information, replace that direct call with a callback.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-7-git-send-email-ander.conselvan.de.oliveira@intel.com
Move register write from intel_dp_update_link_train() into
intel_dp_set_signal_levels(). This creates a better split between the
i915 specific code and the generic link training part. Note that this
causes an extra register write in intel_dp_reset_link_train(), since
both intel_dp_set_signal_levels() and intel_dp_set_link_train() write
to the DP register.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-5-git-send-email-ander.conselvan.de.oliveira@intel.com
Move the call to intel_dp_get_adjust_train() out of
intel_dp_update_link_train() and call it instead from the clock recovery
and channel equalization features. A follow up patch will remove the DP
register write from that function, so that it handles only the DPCD
write.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-4-git-send-email-ander.conselvan.de.oliveira@intel.com
It just makes the code more confusing, so just reference intel_dp_>DP
directly.
Note that this also fix a bug where the value of intel_dp->DP could be
different than the last value written to the hw, due to an early return
that would skip the 'intel_dp->DP = DP' line.
v2: Don't preserve old DP value on failure. (Sivakumar)
- Don't call drm_dp_clock_recovery_ok() twice. (Sivakumar)
- Keep return type of clock recovery and channel equalization
functions as void. (Ander)
v3: Remove DP parameter from intel_dp_set_signal_levels(). (Sivakumar)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-2-git-send-email-ander.conselvan.de.oliveira@intel.com
SWF18 is set if the display has been initialized by the pre-os. It also
gives what configuration is enabled on which pipe. In skl_sanitize_cdclk,
the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS
enables DPLL for integrated audio codec related programming.
So fisrt check if SWF18 is set and then follow through with other DPLL
and CDCLK verification. If not set then for sure we need to sanitize the
cdclock.
v2: Update the commit message for clarity (Siva)
v3: Correct the mask to check for bits[23:0] instead of only bits[16:0].
Had missed checking for PIPE C altogether. Remaining are reserved (Siva)
v4: Use ILK_SWF macro for SWF register definitions. Taken from Ville's patch
http://lists.freedesktop.org/archives/intel-gfx/2015-November/079480.html
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446726932-14078-1-git-send-email-shobhit.kumar@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
BXT CRTC scaling uses the same gen9 codepaths as SKL; these codepaths
store panel fitter information in pipe_config->pch_pfit. However since
HAS_PCH_SPLIT() is false for BXT we never actually wind up filling in
this structure (we wind up filling in pipe_config->gmch_pfit instead,
which is ignored when we go to program the hardware). Make sure we
always take the PCH code path on gen9+ platforms.
v2: Use HAS_GMCH_DISPLAY() to more cleanly describe the platforms that
actually want to use GMCH-style panel fitting. (Ville)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446656727-3516-1-git-send-email-matthew.d.roper@intel.com
I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.
Credits-to: Damien Lespiau <damien.lespiau@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445964628-30226-2-git-send-email-paulo.r.zanoni@intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Make pinning and waiting a separate step, and wait for object idle
without struct_mutex held.
Changes since v1:
- Do not wait when a reset is in progress.
- Remove call to i915_gem_object_wait_rendering for
intel_overlay_do_put_image (Chris Wilson)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
struct_mutex is being locked for every plane in intel_prepare_plane_fb
and intel_cleanup_plane_fb.
Require the caller to hold the mutex, and only acquire the mutex for
each helper call. This way the lock only needs to be acquired
twice in ->atomic_commit(). Once for pinning new framebuffers at the
start, the second time for unpinning old framebuffer.
Changes since v1:
- Use mutex_lock_interruptible instead of i915 variant,
to prevent a deadlock when called from the reset code.
Changes since v2:
- Clarify struct_mutex is locked by the caller.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com> #v1
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Move it from intel_crtc_atomic_commit to prepare_plane_fb.
Waiting is done before committing, otherwise it's too late
to undo the changes.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.
V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes
V3: Corrected state->src_x & 0x00ff to state->src_x & 0xffff...
Signed-off-by: Robert Fekete <robert.fekete@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1445961512-25317-1-git-send-email-robert.fekete@linux.intel.com
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
One branch of the if clause uses pr_info, the other pr_err; change
the 'false' branch to also use pr_info. This minor oversight has gone
unfixed since the initial vga_switcheroo implementation in 6a9ee8af.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446246960-22620-1-git-send-email-adi@adirat.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Imre Deak