| Age | Commit message (Collapse) | Author |
|---|
|
During S4 freeze we don't call intel_suspend_complete(), which would
save the gunit HW state, but during S4 thaw/restore events we call
intel_resume_prepare() which restores it, thus ending up in a corrupted
HW state.
Fix this by calling intel_suspend_complete() from the corresponding
freeze_late event handler.
The issue was introduced in
commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble <sagar.a.kamble@intel.com>
Date: Wed Aug 13 23:07:06 2014 +0530
CC: Sagar Kamble <sagar.a.kamble@intel.com>
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>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Global GTT doesn't have pat_sel[2:0] so it always point to pat_sel = 000;
So the only way to avoid screen corruptions is setting PAT 0 to Uncached.
MOCS can still be used though. But if userspace is trusting PTE for
cache selection the safest thing to do is to let caches disabled.
BSpec: "For GGTT, there is NO pat_sel[2:0] from the entry,
so RTL will always use the value corresponding to pat_sel = 000"
- System agent ggtt writes (i.e. cpu gtt mmaps) already work before
this patch, i.e. the same uncached + snooping access like on gen6/7
seems to be in effect.
- So this just fixes blitter/render access. Again it looks like it's
not just uncached access, but uncached + snooping. So we can still
hold onto all our assumptions wrt cpu clflushing on LLC machines.
v2: Cleaner patch as suggested by Chris.
v3: Add Daniel's comment
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=85576
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Stable@vger.kernel.org
Tested-by: James Ausmus <james.ausmus@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.
Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.
Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Add the new flags argument to calls of (devm_)gpiod_get*() and remove
any direction setting code afterwards.
Currently both forms (with or without the flags argument) are valid
thanks to transitional macros in <linux/gpio/consumer.h>. These macros
will be removed once all consumers are updated and the flags argument
will become compulsary.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
These two functions allow drivers to reuse their atomic plane helpers
functions for the primary plane to implement the interfaces required
by the crtc helpers for the legacy ->set_config callback.
This is purely transitional and won't be used once the driver is fully
converted. But it allows partial conversions to the atomic plane
helpers which are functional.
v2:
- Use ->atomic_duplicate_state if available.
- Don't forget to run crtc_funcs->atomic_check.
v3: Shift source coordinates correctly for 16.16 fixed point.
v4: Don't forget to call ->atomic_destroy_state if available.
v5: Fixup kerneldoc.
v6: Reuse the plane_commit function from the transitional plane
helpers to avoid too much duplication.
v7:
- Remove some stale comment.
- Correctly handle the lack of plane->state object, necessary for
transitional use.
v8: Fixup an embarrassing h/vdisplay mixup.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Converting a driver to the atomic interface can be a daunting
undertaking. One of the prerequisites is to have full universal planes
support.
To make that transition a bit easier this patch provides plane helpers
which use the new atomic helper callbacks just only for the plane
changes. This way the plane update functionality can be tested without
being forced to convert everything at once.
Of course a real atomic update capable driver will implement the
all plane properties through the atomic interface, so these helpers
are mostly transitional. But they can be used to enable proper
universal plane support, especially once the crtc helpers have also
been adapted.
v2: Use ->atomic_duplicate_state if available.
v3: Don't forget to call ->atomic_destroy_state if available.
v4: Fixup kerneldoc, reported by Paulo.
v5: Extract a common plane_commit helper and fix some bugs in the
plane_state setup of the plane_disable implementation.
v6: Fix issues with the cleanup of the old fb. Since transitional
helpers can be mixed we need to assume that the old fb has been set up
by a legacy path (e.g. set_config or page_flip when the primary plane
is converted to use these functions already). Hence pass an additional
old_fb parameter to plane_commit to do that cleanup work correctly.
v7:
- Fix spurious WARNING (crtc helpers really love to disable stuff
harder) and fix array index bonghits.
- Correctly handle the lack of plane->state object, necessary for
transitional use.
- Don't indicate failure if drm_vblank_get doesn't work - that's
expected when the pipe is in dpms off mode.
v8: Review from Sean:
- s/fail/out/ to make the meaning of a label more clear.
- spelling fix in the commit message.
Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This is the first cut of atomic helper code. As-is it's only useful to
implement a pure atomic interface for plane updates.
Later patches will integrate this with the crtc helpers so that full
atomic updates are possible. We also need a pile of helpers to aid
drivers in transitioning from the legacy world to the shiny new atomic
age. Finally we need helpers to implement legacy ioctls on top of the
atomic interface.
The design of the overall helpers<->driver interaction is fairly
simple, but has an unfortunate large interface:
- We have ->atomic_check callbacks for crtcs and planes. The idea is
that connectors don't need any checking, and if they do they can
adjust the relevant crtc driver-private state. So no connector hooks
should be needed. Also the crtc helpers integration will do the
->best_encoder checks, so no need for that.
- Framebuffer pinning needs to be done before we can commit to the hw
state. This is especially important for async updates where we must
pin all buffers before returning to userspace, so that really only
hw failures can happen in the asynchronous worker.
Hence we add ->prepare_fb and ->cleanup_fb hooks for this resources
management.
- The actual atomic plane commit can't fail (except hw woes), so has
void return type. It has three stages:
1. Prepare all affected crtcs with crtc->atomic_begin. Drivers can
use this to unset the GO bit or similar latches to prevent plane
updates.
2. Update plane state by looping over all changed planes and calling
plane->atomic_update. Presuming the hardware is sane and has GO
bits drivers can simply bash the state into the hardware in this
function. Other drivers might use this to precompute hw state for
the final step.
3. Finally latch the update for the next vblank with
crtc->atomic_flush. Note that this function doesn't need to wait
for the vblank to happen even for the synchronous case.
v2: Clear drm_<obj>_state->state to NULL when swapping in state.
v3: Add TODO that we don't short-circuit plane updates for now. Likely
no one will care.
v4: Squash in a bit of polish that somehow landed in the wrong (later)
patche.
v5: Integrate atomic functions into the drm docbook and fixup the
kerneldoc.
v6: Fixup fixup patch squashing fumble.
v7: Don't touch the legacy plane state plane->fb and plane->crtc. This
is only used by the legacy ioctl code in the drm core, and that code
already takes care of updating the pointers in all relevant cases.
This is in stark contrast to connector->encoder->crtc links on the
modeset side, which we still need to set since the core doesn't touch
them.
Also some more kerneldoc polish.
v8: Drop outdated comment.
v9: Handle the state->state pointer correctly: Only clearing the
->state pointer when assigning the state to the kms object isn't good
enough. We also need to re-link the swapped out state into the
drm_atomic_state structure.
v10: Shuffle the misplaced docbook template hunk around that Sean spotted.
Cc: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
internally enforced by always calling ->atomic_check before
->atomic_commit. And async handling needs to be solved differently
because the current scheme completely side-steps ww mutex deadlock
avoidance (and so either reinvents a new deadlock avoidance wheel or
like the current code just deadlocks).
- State for connectors needed to be added, since now they have a
full-blown drm_connector_state (so that drivers have something to
attach their own stuff to).
- Refcounting is gone. I plane to solve async updates differently,
since the lock-passing scheme doesn't cut it (since it abuses ww
mutexes). Essentially what we need for async is a simple ownership
transfer from the caller to the driver. That doesn't need full-blown
refcounting.
- The acquire ctx is a pointer. Real atomic callers should have that
on their stack, legacy entry points need to put the right one
(obtained by drm_modeset_legacy_acuire_ctx) in there.
- I've dropped all hooks except check/commit. All the begin/end
handling is done by core functions and is the same.
- commit/check are just thin wrappers that ensure that ->check is
always called.
- To help out with locking in the legacy implementations I've added a
helper to just grab all locks in the backoff case.
v2: Add notices that check/commit can fail with EDEADLK.
v3:
- More consistent naming for state_alloc.
- Add state_clear which is needed for backoff and retry.
v4: Planes/connectors can switch between crtcs, and we need to be
careful that we grab the state (and locks) for both the old and new
crtc. Improve the interface functions to ensure this.
v5: Add functions to grab affected connectors for a crtc and to recompute
the crtc->enable state. This is useful for both helper and atomic ioctl
code when e.g. removing a connector.
v6: Squash in fixup from Fengguang to use ERR_CAST.
v7: Add debug output.
v8: Make checkpatch happy about kcalloc argument ordering.
v9: Improve kerneldoc in drm_crtc.h
v10:
- Fix another kcalloc argument misorder I've missed.
- More polish for kerneldoc.
v11: Clarify the ownership rules for the state object. The new rule is
that a successful drm_atomic_commit (whether synchronous or asnyc)
always inherits the state and is responsible for the clean-up. That
way async and sync ->commit functions are more similar.
v12: A few bugfixes:
- Assign state->state pointers correctly when grabbing state objects -
we need to link them up with the global state.
- Handle a NULL crtc in set_crtc_for_plane to simplify code flow a bit
for the callers of this function.
v13: Review from Sean:
- kerneldoc spelling fixes
- Don't overallocate states->planes.
- Handle NULL crtc in set_crtc_for_connector.
v14: Sprinkle __must_check over all functions which do wait/wound
locking to make sure callers don't forget this. Since I have ;-)
v15: Be more explicit in the kerneldoc when functions can return
-EDEADLK what to do. And that every other -errno is fatal.
v16: Indent with tabs instead of space, spotted by Ander.
v17: Review from Thierry, small kerneldoc and other naming polish.
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
These counters are used for Displayort compliance testing to detect error
conditions when executing tests 4.2.2.4 and 4.2.2.5 in the Displayport Link
CTS specificaiton. They determine whether to use the preferred/requested
mode or the failsafe mode during these tests.
V2:
- Addressed previous review feedback
- Updated commit message
- Changed from uint8_t to uint32_t
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Todd Previte <tprevite@gmail.com>
[danvet: s/uint32_t/unsigned/ for clearer intent. Also drop the i915
from the subject, it's all core stuff.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.
Maybe this helps to encourage driver maintainers to do the switch.
v2: Fix #include ordering for tegra, reported by 0-day builder.
v3: Include required headers, reported by Thierry.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
|
|
This shouldn't change the behavior of those functions, since they are
called after the new_config is made effective and that points to the
current config. In a follow up patch, the mode set sequence will be
changed so this is called before disabling crtcs, and in that case
those functions should work on the staged config.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
[danvet: Flatten if by moving the check into the WARN.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
execlists_submit_context() always returns 0, which is redundant.
And its name is inaccurate, since it actually submits (up to)
TWO contextS. So we rename it, change it to "void", and remove
the WARN_ON() testing its return value.
Change-Id: Ie225b0eca7754c6093c8b8bd15550b251b6feb82
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
If a ring failed to initialise for any reason then the error path would try to
clean up all rings including those that had not yet been allocated. The ring
clean up code did a check that the ring was valid before starting its work.
Unfortunately, that was after it had already dereferenced the ring to obtain a
dev_private pointer.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When looking at the bug report logs with triggered
WARN_ON, the person doing bug triaging will have to
find exact kernel source and match file/line.
Attach the condition that triggered the WARN_ON
to kernel log. In most cases the context is self
evident and this way we can save developer time.
The drawback is ~16kbytes bigger i915.ko
Signed-off-by: Mika Kuoppala <miku@iki.fi>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When we suspend we turn everything off so the pps should be idle, and we
also (or at least should) disable all power wells which will reset the
power sequencer port assignment. So when we resume all power sequencers
should be in their reset state. However it's at least theoretically
possible that the BIOS would touch the power seuqencer(s), so to be safe
we ought to read out the current port assignment like we do at driver
init time.
To do that we can simply call vlv_initial_power_sequencer_setup() from
the encoder ->reset() hook before calling intel_edp_panel_vdd_sanitize().
There's no danger or clobbering the pps delays since we now have those
stored within intel_dp and we don't change them once initialized.
This will make sure that the vdd state gets correctly tracked post-resume
in case the BIOS enabled it.
We need to shuffle things around a bit to get the locking right, and
while at it, make intel_edp_panel_vdd_sanitize() static and move it
around a bit to avoid a forward declaration.
Cc: Imre Deak <imre.deak@intel.com>
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>
|
|
The pps timestamp initialization was accidentally lost on vlv/chv in
commit a4a5d2f8a96e09844a91469e889f15bd5e927399
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Sep 4 14:54:20 2014 +0300
drm/i915: Track which port is using which pipe's power sequencer
Restore it so that we avoid introducing random delays into the pps operations
during/after driver init time.
Cc: Imre Deak <imre.deak@intel.com>
Reported-by: Imre Deak <imre.deak@intel.com>
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>
|
|
We'll never end up in the hooks with eld[0] unset, as that's checked by
drm_select_eld().
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Introduce functions to enable/disable the audio codec, incorporating the
ELD setup within enable. The disable is initially limited to HSW,
covering exactly what was done previously.
The only functional difference is that ELD valid is no longer set if
there is no connector with ELD, which should be the right thing to do
anyway. Otherwise the sequence remains the same, with warts and all, in
preparation for applying more sanity.
v2: add kernel doc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The audio programming sequence states that the ELD must be written and
enabled after the pipe is ready. Indeed, this should clarify the
situation with
commit c79057922ed6c2c6df1214e6ab4414fea1b23db2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 16 16:56:09 2014 +0200
drm/i915: Remove vblank wait from haswell_write_eld
and Ville's review of it [1].
Moreover, we should not touch the relevant registers before we get the
audio power domain.
[1] http://mid.gmane.org/20140416155309.GK18465@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Keep the driver modifications to ELD together. This also sets the
Conn_Type for G4X DP which wasn't done before.
Clean up the debugs while at it; this is all obvious from the connector
name.
v3: add missing ~ (Rodrigo)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
It seems that the pipe-a power well has replaced the disp2d power well
on chv. At least that's the case with the current punit firmware. So
enable the pipe-a power and expand its domains to cover everything the
disp2d well ought to cover.
The other power wells (apart from the cmnlane wells) still seem awol
in the current punit firmware. So leave them disabled in the code.
This fixes a hilarious oops during resume on bsw where
intel_hdmi_get_config() would read the port register and get back
0xffffffff and thus think the port is enabled on pipe D. It would then
go and index the pipe_to_crtc_mapping[] array with PIPE_D and blow up
when intel_hdmi_get_config() tries to write to crtc->config. Someone
really ought to replace all naked pipe_to_crtc_mapping[] uses with the
appropriate function call so we could add a warning there if the pipe
doesn't actually exist...
We must also call the power seqeuencer state reset function from
the pipe-a well disable just like we do from disp2d on vlv. Otherwise
the eDP panel won't recover at resume time since the PPS has lost its
hold on the port.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84903
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
CHV has a programmable CSC unit on the pipe B sprites. Program the unit
appropriately for BT.601 limited range YCbCr to full range RGB color
conversion. This matches the programming we currently do for sprites
on the other pipes and on other platforms.
It seems the CSC only works when the input data is YCbCr. For RGB
pixel formats it doesn't matter what we program into the CSC registers.
Doesn't make much sense to me especially since the register names give
the impression that RGB input data would also work. But that's how
it behaves here.
In the review discussions there's been some nice math to explain the
values obtained here. First about the YCbCr->RGB matrix:
"I had the RGB->YCbCr matrix, inverted it and the values came out. But they
should match the wikipedia article. Also keep in mind that the coefficients
are in .12 in fixed point format, hence we need a 1<<12 factor. So let's
try it:
Kb=.114
Kr=.299
(1<<12) * 255/219 ~= 4769
-(1<<12) * 255/112*(1-Kb)*Kb/(1-Kb-Kr) ~= -1605
-(1<<12) * 255/112*(1-Kr)*Kr/(1-Kb-Kr) ~= -3330
(1<<12) * 255/112*(1-Kr) ~= 6537
(1<<12) * 255/112*(1-Kb) ~= 8263
"Looks like the same values to me."
And then about the limits used for clamping:
"> where did you get these min/max?
"The hardware apparently deals in 10bit values, so we need to multiply everything
by 4 when we start with the 8bit min/max values.
Y = [16:235] * 4 = [64:940]
CbCr = ([16:240] - 128) * 4 = [-112:112] * 4 = [-448:448]
"The -128 being the -0.5 bias that the hardware already applied before
the data entered the CSC unit."
Raw data is also supplied in 10bpc in the registers.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Rodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Copypaste explanations&math from the review discussion.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We want to run intel_uncore_early_sanitize() before we touch any
registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit
is set, so we need to clear it - through intel_uncore_early_sanitize()
- before we do anything else. With the current code, we don't clear
the bit before our first register access, so we print a WARN
complaining about an unclaimed register error.
v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
resume"
v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on
resume on non-VLV"
v3: This one, on top of the intel_resume_prepare() rework.
v4: 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>
|
|
Because, really, the abstraction is not working for us. It is nice for
VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change
this code due to a recently-discovered bug, but we can't seem to find
a nice solution that repects the current abstraction. So let's kill
intel_resume_prepare() and its friends, and add an equivalent
implementation to both its callers.
Also, look at the diffstat!
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>
|
|
CHV adds a bunch of new registers for primary plane size/position and
pipe blender setup. Initialize all those registers to avoid nasty
surprises. PRIMSIZE is especially important as without programming it
the outout will be garbled whenever the primary plane size would not
match what the BIOS set up.
Also program the sprite constant alpha register to disable the constant
alpha blending factor. This applies to vlv as well as chv.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
In case the cmnlane power well is down but cmnreset isn't asserted we
would currently skip the off+on toggle for the power well. That could
leave cmnreset deasserted while cmnlane is powered down which might
lead to problems with the PHY.
To avoid such issues skip the cmnlane toggle only if both cmnlane and
disp2d wells are up and cmnreset is already deasserted. In all other
cases power down the cmnlane well which will also make sure cmnreset
gets asserted correctly while cmnlane is powered down.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Use the macros makes the code cleaner and it also checks for a NULL fb.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
take out pin_fb code so the commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The power seqeuencer kick procedure requires the DPLL to be running
in order to complete successfully. In case the DPLL isn't currently
running when we need to kick the power seqeuncer enable it
temporarily. This can happen eg. during ->detect() when the pipe is
not already active.
To avoid needlessly duplicating the DPLL programming re-use the already
existing functions by passing a temporary pipe config to them instead
of having them consult the current pipe config at crtc->config.
v2: Introduce vlv_force_pll_{on,off}() (Daniel)
v3: Rebase due to drm_crtc vs. intel_crtc changes
Fix a typo in commit msg (checkpatch)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
eDP ports need the power seqeuncer whenever the port is active. Warn if
we accidentally steal the power sequener from an active eDP port. This
should not happen unless there's a bug somewhere else, but it's best to
scream loudly if it happens to help with debugging.
Note that this only checks for active pipes and not for enabled pipes
which are turned off with dpms. Which means we might run the risk that
the pps might get stolen and we can't reacquire one when enabling the
pipe again with dpms on. But on current platforms that's impossible
since we only support two edp ports with just two panel power
sequencers. So a more elaborate scheme which reserves the pps even
when the pipe is inactive isn't required.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Summarize my discussion with Ville about dpms on/off issues.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
We should never enable the panel power twice. That would indicate a bug
somewhere else as we would need to enable the port twice without
disabling it in between. Also print the port name.
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>
|
|
Print the port name in the VDD/PPS debugs messages.
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>
|
|
In case we fumble something and end up picking an already used power
seqeuencer in vlv_power_sequencer_pipe() at least try to steal it
gracefully. In theory this should never happen though.
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>
|
|
There's no power sequencer on pipe C on VLV/CHV so scream a bit if we
try to steal one from pipes other than A and B.
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>
|
|
VLV gets confused if two power sequencers have the same port selected.
It would seem the port doesn't start up properly in the is case and
vlv_wait_port_ready() will fail as will the link training. Clearing the
port select in the PP_ON_DELAYS register fixes this problem.
CHV doesn't seem to need this, but it doesn't seem to hurt either so
let's just do it for both to keep the code between the platforms as
uniform as possible.
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>
|
|
power
If there's no power sequencer assigned to the port currently we can't
very well have vdd or panel power enabled either. If we would try to
check that from the pps registers we'd need to pick a power seqeuncer
and kick it. So let's skip the register read and the kick.
Note that there's still a bit an issue about correctly recovering pps
state from resume if the bios is nasty: With this check we'll always
assume that the pps is off. But that's better done in a follow-up
patch and it shouldn't be too harmful - at most we waste time enabling
the pps if it's on already.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Add note about resume issues Imre spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
When we pick a new power sequencer for the port but we're not doing a
full modeset, the power sequencer may have locked on to another port (or
no port). So kick it a bit to make sure it controls the port we want.
Again just like when we attempt to actually enable the DP port, we
must first write the port register with the approriate value except
the enable bit, and then we must enable the port to make the power
sequencer happy. In this case since we don't want the port actually
enabled we just toggle it on and immediately back off. Going forward
the power sequencer will keep working on that specific port until again
moved to another port.
v2: Refine the kick procedure
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>
|
|
When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done before any AUX transactions are attempted.
After extensive experimentation I've determined that it's sufficient
to first write the port register with the correct values except the
port must remain disabled, then we can do a second write to enable the
port, after which the power sequencer is operational and allows the port
to start up properly.
Contrary to my earlier theories we don't need to enable the port with
the idle pattern, so let's just use training pattern 1 as that's what
other platforms use here.
v2: Refine the kick procedure
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>
|
|
There's no point in checking if the data lanes came out of reset after
link training. If the data lanes aren't ready link training will fail
anyway.
Suggested-by: Todd Previte <tprevite@gmail.com>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Acked-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Just grab the pps_mutex once and do all the pps panel startup operations
while holding the mutex instead of grabbing the mutex separately for
each individual step.
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>
|
|
unlocked variants
We'll be needing to the call the power seqeuencer functions while
already holding pps_mutex, so split the locking out to small wrapper
functions.
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>
|
|
Since we read the current power seqeuncer delays from the registers
(as well as looking at the vbt and spec values) we may end up
corrupting delays we already initialized when we switch to another
pipe and the power seqeuncer there has different values currently
in the registers.
So make sure we only initialize the delays once even if
intel_dp_init_panel_power_sequencer() gets called multiple times.
There was some discussion in the review about when exactly we need to
unlock the pps. Quoting Bspec:
"If this bit is not a zero, it activates the register write protect
and writes to those registers will be ignored unless the write
protect key value is set in the panel sequencing control register."
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Add Bspec quote per review discussion between Imre and
Ville.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
The power seqeuncer delays are fixed for a given panel, so we can keep
them around once computed.
Not that on VLV/CHV we still re-compute them every time we initialize
the power seqeuncer registers, but that will change soon enough.
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>
|
|
want_panel_vdd is a bool so it can't cope with interleaving on/off calls
from multiple threads. If we want to make that possible we'd need to
convert want_panel_vdd into a proper ref count. But an easier fix is to
remove the high level vdd on/off calls from detect/hpd code paths and
just rely on the delayed vdd off to avoid needless vdd on<->off ping
pong.
After this change only the encoder enable/disable paths use the high
level functions, which is fine since both the on and off low level edp
vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in
between and so want_panel_vdd can't change in between.
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>
|
|
Only ports B and C have the power sequencer and backlight controls,
so complain if we ever try to register an eDP connector on some other
port.
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>
|
|
Because I got annoyed that I had to document what values "int
ddi_personality" is supposed to hold.
A good side-effect of this change is that now the compilers can do
some additional checks on our code, which may prevent some bugs in the
future. A bad side-effect of this change is that now the compilers do
some additional checks on our code and complain when a switch
statement doesn't check for all possible values, so we need to add
"default" cases to all those switches. Hopefully, this may help
preventing confusions against DRM_MODE_CONNECTOR_* and
DRM_MODE_ENCODER_*.
I guess that just by looking at the patch, some people will think this
change is not worth its benefits. In this case, I don't really mind
dropping the patch.
Also, there's probably still a few more places where we can
s/int/enum intel_output_type/, but we can change that later, when we
spot the places.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
This will simplify things later on. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
|
Everything else can be derived from that. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
|
