Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
Minor checkpatch fixes sprinkled on top of the changed lines.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14ed72e7f04c9340a057855c5950b54811f8a477.1547629303.git.jani.nikula@intel.com
On module load and unload, we grab the POWER_DOMAIN_INIT powerwells and
transfer them to the runtime-pm code. We can use our wakeref tracking to
verify that the wakeref is indeed passed from init to enable, and
disable to fini; and across suspend.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-17-chris@chris-wilson.co.uk
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-16-chris@chris-wilson.co.uk
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
For regular builds, the compiler should be able to eliminate the unused
local variables and the program growth should be minimal. Fwiw, it came
out as a net improvement as gcc was able to refactor rpm_get and
rpm_get_if_in_use together,
v2: Just s/rpm_put/rpm_put_unchecked/ everywhere, leaving the manual
mark up for smaller more targeted patches.
v3: Mention the cookie in Returns
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-2-chris@chris-wilson.co.uk
Everytime we take a wakeref, record the stack trace of where it was
taken; clearing the set if we ever drop back to no owners. For debugging
a rpm leak, we can look at all the current wakerefs and check if they
have a matching rpm_put.
v2: Use skip=0 for unwinding the stack as it appears our noinline
function doesn't appear on the stack (nor does save_stack_trace itself!)
v3: Allow rpm->debug_count to disappear between inspections and so
avoid calling krealloc(0) as that may return a ZERO_PTR not NULL! (Mika)
v4: Show who last acquire/released the runtime pm
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-1-chris@chris-wilson.co.uk
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
On Icelake, a separate power well PG2 is created for
VDSC engine used for eDP/MIPI DSI. This patch adds a new
display power domain for Power well 2.
v3:
* Call it POWER_DOMAIN_TRANSCODER_EDP_VDSC (Ville)
* Move it around TRANSCODER power domain defs (Ville)
v2:
* Fix the power well mismatch CI error (Ville)
* Rename as VDSC_PIPE_A (Imre)
* Fix a whitespace (Anusha)
* Fix Comments (Imre)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-7-manasi.d.navare@intel.com
Even though PW#1 and the MISC_IO power wells are managed by the
DMC firmware (toggled dynamically if conditions allow it) from the
driver's POV they are always on if the display core is initialized
(always restored by DMC to the enabled state after exiting from DC5/6
for instance b/c of MMIO access). Accordingly we can just mark them as
always-on and remove the special casing for them during state
verification (thus enabling verification for these power wells too).
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-3-imre.deak@intel.com
We can just use a proper true/false initializer even for bitfields,
which is more descriptive.
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-2-imre.deak@intel.com
A DMC bug on GEN9 big core machines fails to restore the driver's
request bits for the PW1 and MISC_IO power wells after a DC5/6
entry->exit sequence. As a consequence the driver's subsequent check for
the enabled status of these power wells will fail, as the check
considers the power wells being enabled only if both the status and
request bits are set. To work around this borrow the request bits from
BIOS's own request register in which DMC forces on the request bits when
exiting from DC5/6.
This fixes a problem reported by Ramalingam, where HDCP init failed,
since PW1 reported itself as being disabled, while in reality it was
enabled.
Reported-by: Ramalingam C <ramalingam.c@intel.com>
Cc: Ramalingam C <ramalingam.c@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109145822.15446-1-imre.deak@intel.com
Register DBUF_CTL_S2 is read and it's value is not used. As
there is no explanation why we should prime the hardware with
read, remove it as spurious.
Fixes: aa9664ffe8 ("drm/i915/icl: Enable 2nd DBuf slice only when needed")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181109140924.2663-1-mika.kuoppala@linux.intel.com
On ICL DMC/PCODE retains the HW context only for port A across DC
transitions, for the other port B combo PHY, it doesn't. So we need to
do this manually after exiting from DC6. Do the reinit even after
exiting from DC5, it won't hurt since we only reinit the PHY in case
it's needed (in case it was disabled to begin with).
As can be guessed from the bugzilla report leaving the PHY uninited will
lead to a later timeout during the port B specific AUX and DDI_IO power
well enabling.
v2:
- Apply the fix on all GEN>=11 platforms. (Rodrigo)
Bspec: 21257
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108070
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-6-imre.deak@intel.com
Similarly to the GEN9_LP DPIO PHY code keep the CNL+ combo PHY code in a
separate file.
No functional change.
v2:
- Use SPDX license tag instead of boilerplate. (Rodrigo)
v3:
- Use MIT instead of GPL-2.0 license. (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-3-imre.deak@intel.com
BSpec says to clear the comp init HW flag too during combo PHY uninit,
so do that. The lack of this could badly interact with the PHY reinit
after a DC6/9 transition at least, where (after a follow-up patch fixing
the init code) we'd skip the initialization incorrectly due to this flag
being set.
BSpec: 21257
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181106160621.23057-2-imre.deak@intel.com
To enable DC5/6 power well 2 has to be disabled as for previous
platforms, so fix things up.
Bspec: 4234
Fixes: 67ca07e7ac ("drm/i915/icl: Add power well support")
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181102182200.17219-1-imre.deak@intel.com
Most of the AUX_CH_CTL flags are concerned with DP AUX transfer
parameters. As opposed to this the flag specifying the thunderbolt vs.
non-thunderbolt mode of the port is not related to AUX transfers at all
(rather it's repurposed to enable either TBT or non-TBT PHY HW blocks).
The programming has to be done before enabling the corresponding AUX
power well, so make it part of the power well code.
v3:
- Use existing enable/disable helpers instead of opencoding. (Jose)
- Fix type of is_tc_tbt to remain a bitfield. (Lucas)
- Add comment describing the is_tc_tbt power well flag. (Lucas)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108548
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181101140427.31026-8-imre.deak@intel.com
ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable
DC5/6 when appropriate.
v2: (James Ausmus)
- Also handle ICL as GEN9_LP in i915_drm_suspend_late and
i915_drm_suspend_early
- Add DC9 to gen9_dc_mask for ICL
- Re-order GEN checks for newest platform first
- Use INTEL_GEN instead of INTEL_INFO->gen
- Use INTEL_GEN >= 11 instead of IS_ICELAKE
- Consolidate GEN checks
v3: (James Ausmus)
- Also allow DC6 for ICL (Imre, Art)
- Simplify !(GEN >= 11) to GEN < 11 (Imre)
v4: (James Ausmus)
- Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
PPS regs are Always On
- Rebase against upstream changes
v5: (Anusha Srivatsa)
- rebased against the latest upstream changes.
v6: (Anusha Srivatsa)
- rebased.Use INTEL_GEN consistently.
- Simplify the code (Rodrigo)
v7: rebased. Change order according to platforms(Jyoti)
v8: rebased. Change the check from platform specific to
HAS_PCH_SPLIT(). Add comment in code to be more clear.(Rodrigo)
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Tested-by: Jyoti Yadav <jyoti.r.yadav@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029221410.4423-1-anusha.srivatsa@intel.com
Display WA #1178 is meant to fix Aux channel voltage swing too low with
some type C dongles. It applies to external ports on combo phy. On
Icelake this is port A and B when those are not eDP.
v2: follow the spec to the letter: include Aux A and just check if it's
not eDP instead of checking only for Aux B.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181012215758.25342-1-lucas.demarchi@intel.com
Right now RESET_PCH_HANDSHAKE_ENABLE is enabled all the times inside
of intel_power_domains_init_hw() and if PCH is NOP it is unsed in
i915_gem_init_hw().
So making skl_pch_reset_handshake() handle both cases and calling
it for the missing gens in intel_power_domains_init_hw().
Ivybridge have a different register and bits but with the same
objective so moving it too.
v2(Rodrigo):
- handling IVYBRIDGE case inside intel_pch_reset_handshake()
v4(Rodrigo and Ville):
- moving the enable/disable decision to callers
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-2-jose.souza@intel.com
Instead of have the same code spread into 4 platforms lets share it.
BXT do not have a PCH so here also handling this case by unseting
RESET_PCH_HANDSHAKE_ENABLE.
v2(Rodrigo):
- renamed to intel_pch_reset_handshake()
- added comment about why BXT need the bit to be unset
v3(Rodrigo and Ville):
- added bool have_pch to intel_pch_reset_handshake()
- added back BXT comment
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180918204714.27306-1-jose.souza@intel.com
PSR requires AUX IO power well to be enabled. This was already in place
for CNL, extend this for ICL too. Not enabling the power well results in
the aux error interrupts when the hardware exits PSR.
Reported-by: Casey G Bowman <casey.g.bowman@intel.com>
Reported-by: Jyoti R Yadav <jyoti.r.yadav@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Jyoti R Yadav <jyoti.r.yadav@intel.com>
Cc: Casey G Bowman <casey.g.bowman@intel.com>
Tested-by: Casey G Bowman <casey.g.bowman@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180914001822.2503-1-dhinakaran.pandiyan@intel.com
Add Support to load DMC on Icelake.
While at it, also add support to load the firmware
during system resume.
v2: load firmware during system resume.(Imre)
v3: enable has_csr for icelake.(Jyoti)
v4: Only load the firmware in this patch
Cc: Jyoti Yadav <jyoti.r.yadav@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828003844.4682-2-anusha.srivatsa@intel.com
During power domains initialization we acquire power well references for
power wells in the INIT power domain. The rest of power wells - which
BIOS could have left enabled - we can only acquire references as needed
during display HW readout and so must defer sanitization until then
(also implying that we must always do HW readout to cleanup unused power
wells).
Thus during initialization these latter power wells can have a refcount
of 0 while still being enabled. To avoid the false-positive state
mismatch error this causes remove the check from
intel_power_domains_init_hw() and rely on the state check in
intel_power_domains_enable() which follows the HW readout.
v2:
- Add comment to log and code clarifying how unused power wells get
disabled. (Chris)
Fixes: 6dfc4a8f13 ("drm/i915: Verify power domains after enabling them")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=107411
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180828122231.14336-1-imre.deak@intel.com
None of the current lookup_power_well() callers are actually checking
for NULL return values, they all just use the pointer right away. The
first idea was to replace these theoretical segfaults with a BUG()
since this would at least make our code a little more explicit to the
reader. It was suggested that just converting the BUG() to a WARN()
and returning any power well would probably be better since it would
still keep the system running while at the same time exposing the
driver bug.
We can only hit this NULL/BUG()/WARN() condition if we try to lookup a
power well that isn't defined on a given platform. If that ever
happens, we have to fix our code, making it lookup the correct power
well. Because of this, I don't think it's worth trying to implement
error checking in every caller. Improving our CI system will be a
better use of our time once a bug is found in the wild.
v2: Avoid the BUG() with a WARN() return a random PW (Michal).
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180820233139.11936-2-paulo.r.zanoni@intel.com
For S0ix we want to deinit power domains (and so deactivate the DMC
firmware) exactly when the platform supports the DC9 state. To reach
S0ix we need DC9 on these platforms (for which the DMC FW needs to be
deactivated) while to reach S0ix on the rest of the DMC platforms we
need DC6 (which needs the DMC FW to stay active).
Simplify the condition accordingly so it will be automatically
correct for upcoming DC9 platforms like ICL.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180822112602.27543-1-imre.deak@intel.com
After
commit 2cd9a689e9 ("drm/i915: Refactor intel_display_set_init_power() logic")
it makes more sense to check the power domain/well refcounts after
enabling the power domains functionality. Before that it's guaranteed
that most power wells (in the INIT domain) will have a reference held,
so not an interesting state.
While at it also add the check after the init_hw/fini_hw, disable and
suspend/resume steps. Make the test optional on a Kconfig option since
it may add substantial overhead: on VLV/CHV the corresponding PUNIT reg
access for each power well may take up to 20ms.
v2:
- Add the state check to more spots. (Chris)
v3:
- During suspend check the state before deiniting display core.
Afterwards DC states are disabled (and so the dc_off power well is
enabled) even though we don't hold a reference on it.
- Do the test conditionally based on a new Kconfig option. (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[Add DRM_I915_DEBUG_RUNTIME_PM to welcome messages]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180817145837.26592-1-imre.deak@intel.com
The device global init_power_on flag is somewhat arbitrary and makes
debugging power refcounting problems difficult. Instead arrange things
so that all display power domain get has a corresponding put call. After
this change we have the following sequences:
driver loading:
intel_power_domains_init_hw();
<other init steps>
intel_power_domains_enable();
driver unloading:
intel_power_domains_disable();
<other uninit steps>
intel_power_domains_fini_hw();
system suspend:
intel_power_domains_disable();
<other suspend steps>
intel_power_domains_suspend();
system resume:
intel_power_domains_resume();
<other resume steps>
intel_power_domains_enable();
at other times while the driver is loaded:
intel_display_power_get();
...
intel_display_power_put();
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-2-imre.deak@intel.com
Currently, we cancel the extra wakeref we have for !runtime-pm devices
inside power_wells_fini_hw. However, this is not strictly paired with
the acquisition of that wakeref in runtime_pm_enable (as the fini_hw may
be called on errors paths before we even call runtime_pm_enable). Make
the symmetry more explicit and include a check that we do release all of
our rpm wakerefs.
v2: Fixup transfer of ownership back to core whilst keeping our wakeref
count balanced.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180816123757.3286-1-imre.deak@intel.com
There is no need for separate IDs for power wells on a new platform with
the same functionality as an other power well on a previous platform, we
can just reuse the ID from the previous platform. This is only possible
after the previous patches where we removed dependence on the actual
enum values.
This also fixes a problem on ICL where in assert_can_enable_dc5/9() we
would've failed to look up the PW#2 power well.
v2:
- Keep an ID assigned for the ICL PW#2 power well too. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Added comment about the ICL PW#2 fix to the commit log]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-10-imre.deak@intel.com
The format for the ID names is <platform>_DISP_PW_* so rename the IDs
not following this accordingly. Leave BXT_DPIO_CMN_BC as-is since we'll
change that to use another existing ID in the next patch.
v2:
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-9-imre.deak@intel.com
Now that we removed dependence on the power well IDs to determine the
control register and request/status flag offsets the only purpose of
power well IDs is to look up power wells directly bypassing the power
domains framework. However this direct lookup isn't needed for most of
the exisiting power wells and hopefully won't be needed for any new
power wells in the future. To make maintenance of the power well ID enum
easier, don't require a unique ID for each power well, only if it's
necessary. Remove the IDs becoming redundant this way and assign to all
the corresponding power wells a new DISP_PW_ID_NONE ID.
After the previous two patches the IDs don't need to have a fixed value,
so remove the explicit initializers and adjust the enum's code comment
accordingly.
v2:
- Keep required ID assignments for HSW_DISP_PW_GLOBAL and ICL_DISP_PW_2.
(Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-8-imre.deak@intel.com
Similarly to the previous patch use a separate request/status HW flag
index defined right after the corresponding control registers instead of
depending for this on the power well IDs. Since the set of
control/status registers varies among the different power wells (on a
single platform), also add a new i915_power_well_registers struct that
we populate and assign to each DDI power well as needed.
Also clarify a bit the code comment describing the function and layout
of the control registers.
This also fixes a problem on ICL, where we incorrectly read the KVMR
control register in hsw_power_well_requesters() even for DDI and AUX
power wells.
v2:
- Clarify platform range tags in code comments. (Paulo)
- Fix line over 80 chars checkpatch warning.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-7-imre.deak@intel.com
Atm, we determine the control/status flag offsets within the PUNIT
control/status registers based on the power well's ID. Since the power
well ID enum is global across all platforms, the associated macros to
get the flag offsets involves some magic. This makes checking the
register/bit definitions against the specification more difficult than
necessary. Also the values in the power well ID enum must stay fixed,
making code maintenance of the enum cumbersome.
To solve the above define the control/status flag indices right after
the corresponding registers and use these to derive the control/status
flag values by storing the indices in the i915_power_well_desc struct.
Initializing anonymous union fields require the preceding field in the
struct to be explicitly initialized - even when using named
initializers - and the initialization to be done right before the union
initialization, hence the reordering of the .id fields.
v2:
- Clarify commit log message about anonymous union initializers. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-6-imre.deak@intel.com
It makes sense to keep unchanging data const. Extract such fields from
the i915_power_well struct into a new i915_power_well_desc struct that
we initialize during compile time. For the rest of the dynamic
fields allocate an array of i915_power_well objects in i915 dev_priv,
and link to each of these objects their corresponding
i915_power_well_desc object.
v2:
- Fix checkpatch warnings about missing param name in fn declaration and
lines over 80 chars. (Paulo)
- Move check for unique IDs to __set_power_wells().
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Fixed checkpatch warn in __set_power_wells()]
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-5-imre.deak@intel.com
The callbacks these asserts are called from are used from a single power
well, so not much point in checking that. The check also requires a unique
power well ID that we would need to keep around only for this purpose.
(A follow-up patch removes power well IDs not needed for direct power
well access).
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-4-imre.deak@intel.com
intel_power_domains_fini() rolls back what was done in
intel_power_domains_init_hw(), so rename and move it accordingly. This
allows us adding a cleanup function later for intel_power_domains_init()
in a cleaner way.
No functional change.
v2:
- Fix checkpatch error adding missing param name to function
declaration. (Paulo)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-3-imre.deak@intel.com
Similarly to commit 0a445945be
("drm/i915: Work around GCC anonymous union initialization bug")
we need to initialize anonymous unions inside extra braces to work
around a GCC4.4 build error.
v2:
- Fix checkpatch errors in commit log. (Paulo)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180806095843.13294-2-imre.deak@intel.com
The new recommendation from the spec is to simply not set this bit
anymore. Not setting the bit would prevent some hangs that our driver
manages to avoid since commit c8af5274c3 ("drm/i915: enable the
pipe/transcoder/planes later on HSW+"), and the theoretical downside
of not setting the bit doesn't seem realistic according to the HW
team. Let's follow their recommendation.
BSpec: 20233
References: commit c8af5274c3 ("drm/i915: enable the
pipe/transcoder/planes later on HSW+")
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180726001229.13791-1-paulo.r.zanoni@intel.com
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 141432
Addresses-Coverity-ID: 141433
Addresses-Coverity-ID: 141434
Addresses-Coverity-ID: 141435
Addresses-Coverity-ID: 141436
Addresses-Coverity-ID: 1357360
Addresses-Coverity-ID: 1357403
Addresses-Coverity-ID: 1357433
Addresses-Coverity-ID: 1392622
Addresses-Coverity-ID: 1415273
Addresses-Coverity-ID: 1435752
Addresses-Coverity-ID: 1441500
Addresses-Coverity-ID: 1454596
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180628223541.GA17665@embeddedor.com
Add the definition for ICL power wells and their mapping to power
domains. On ICL there are 3 power well control registers, we'll select
the correct one based on higher bits of the power well ID. The offset
for the control and status flags within this register is based on the
lower bits of the ID as on older platforms.
As the DC state programming is also the same as on old platforms we can
reuse the corresponding helpers. For this we mark here the DC-off power
well as shared among multiple platforms.
Other than the above the delta between old platforms and ICL:
- Pipe C has its own power well, so we can save some additional power in the
pipe A+B and (non-eDP) pipe A configurations.
- Power wells for port E/F DDI/AUX IO and Thunderbolt 1-4 AUX IO
v2:
- Rebase on drm-tip after prep patch for this was merged there as
requested by Paulo.
- Actually add the new AUX and DDI power well control regs (Rakshmi)
v3:
- Fix power well register names in code comments
- Add TBT AUX->power well 3 dependency
v4:
- Rebase
v5:
- Detach AUX power wells from the INIT power domain. These power wells
can only be enabled in a TC/TBT connected state and otherwise not
needed during driver initialization.
v6:
- Use _MMIO_PORT(...) instead _MMIO(_PICK(...)) (Paulo)
Fix checkpatch warnings.
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com> (v1)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180626142232.22361-1-imre.deak@intel.com
So far we got an AUX power domain reference only for the duration of DP
AUX transfers. However, the following suggests that we also need these
for main link functionality:
- The specification doesn't state whether it's needed or not for main
link functionality, but suggests that these power wells need to be
enabled already during display core initialization (Sequences to
Initialize Display).
- For PSR we need to keep the AUX power well enabled.
- On ICL combo PHY ports (non-TC) the AUX power well is needed for
link training too: while the port is enabled with a DP link training
test pattern trying to toggle the AUX power well will time out.
- On ICL MG PHY ports (TC) the AUX power well is needed also for main
link functionality (both in DP and HDMI modes).
- Windows enables these power wells both for main and AUX lane
functionality.
Based on the above take an AUX power reference for main link
functionality too. This makes a difference only on GEN10+ (GLK+)
platforms, where we have separate port specific AUX power wells.
For PSR we still need to distinguish between port A and the other
ports, since on port A DC states must stay enabled for main link
functionality, but DC states must be disabled for driver initiated
AUX transfers. So re-use the corresponding helper from intel_psr.c.
Since we take now a reference for main link functionality on all DP
ports we can forgo taking the separate power ref for PSR functionality.
v2:
- Make sure DC states stay enabled when taking the ref on port A.
(Ville)
v3: (Ville)
- Fix comment about logic for encoders without a crtc state and
add FIXME note for a simplification to avoid calling get_power_domains
in such cases.
- Use intel_crtc_has_dp_encoder() instead !intel_crtc_has_type(HDMI).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
[Clarified code comments in intel_ddi_main_link_aux_domain() and
intel_ddi_get_power_domains() (Imre)]
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180621184449.26634-1-imre.deak@intel.com
Add support for DP_AUX_E. Here we also introduce the bits for the AUX
power well E, however ICL power well support is still not enabled yet,
so the power well is not used.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612002512.29783-2-paulo.r.zanoni@intel.com
Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com
ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.
Changes since V1:
- typecast total_data_rate to u64 before multiplication to solve any
possible overflow (Rodrigo)
- fix where skl_wm_get_hw_state was memsetting ddb, resulting
enabled_slices to become zero
- Fix the logic of calculating ddb_size
Changes since V2:
- If no-crtc is part of commit required_slices will have value "0",
don't try to disable DBuf slice.
Changes since V3:
- Create a generic helper to enable/disable slice
- don't return early if total_data_rate is 0, it may be cursor only
commit, or atomic modeset without any plane.
Changes since V4:
- Solve checkpatch warnings
- use kernel types u8/u64 instead of uint8_t/uint64_t
Changes since V5:
- Rebase
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-3-mahesh1.kumar@intel.com
This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.
Changes Since V1:
- use kernel type u8 over uint8_t
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-2-mahesh1.kumar@intel.com
One is outright unused, other can be made static.
Drive-by cleanup while accidentally reading dc code.
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417100225.12286-1-daniel.vetter@ffwll.ch
Jani Nikula