The intel_uncore structure is the owner of register access, so
subclass the function to it.
While at it, use a local uncore var and switch to the new read/write
functions where it makes sense.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-9-daniele.ceraolospurio@intel.com
To allow unsetting .is_mobile for the desktop variant
of PNV fix up the cdclk code to select the mobile HPLLVCO register
for both PNV variants.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190318165633.28924-5-ville.syrjala@linux.intel.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
I just noticed that initial PCH comparative patch
left some >= PCH_ICP cases behind.
Let's also cover these cases and leave only the pin map
behind now.
No functional change. Hence no fixes tag.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190313214307.26573-1-rodrigo.vivi@intel.com
In order to make it easier to bring up new platforms
without having to take care about all corner cases
that was previously taken care for previous platforms
we already use comparative INTEL_GEN statements.
Let's start doing the same with PCH.
The only caveats are:
- less-than comparisons need to be avoided or done with
attention and check > PCH_NONE as well.
- It is not necessarily a chronological order, but a matter
of south display compatibility/inheritance.
v2: Rebased on top of Jani's clean-up which removed the
need for less-than comparison
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308214300.25057-3-rodrigo.vivi@intel.com
This exactly same approach was already used from gen9
to gen10 and from gen10 to gen11. Let's also use it
for gen11+.
Let's first assume that we inherit a similar platform
and than we apply the differences on top.
Different from the previous attempts this will be
done this time with coccinelle. We obviously need to
exclude some case that is really exclusive for gen11
like PCH, Firmware, and few others. Luckly this was
easy to filter by selecting the files we are touching
with coccinelle as exposed below:
spatch -sp_file gen11\+.cocci --in-place i915_perf.c \
intel_bios.c intel_cdclk.c intel_ddi.c \
intel_device_info.c intel_display.c intel_dpll_mgr.c \
intel_dsi_vbt.c intel_hdmi.c intel_mocs.c intel_color.c
@noticelake@ expression e; @@
-!IS_ICELAKE(e)
+INTEL_GEN(e) < 11
@notgen11@ expression e; @@
-!IS_GEN(e, 11)
+INTEL_GEN(e) < 11
@icelake@ expression e; @@
-IS_ICELAKE(e)
+INTEL_GEN(e) >= 11
@gen11@ expression e; @@
-IS_GEN(e, 11)
+INTEL_GEN(e) >= 11
No functional change.
v2: Remove intel_lrc.c per Tvrtko request since those were w/a
for ICL hw issuea and media related configuration.
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308214300.25057-1-rodrigo.vivi@intel.com
No functional change. Just a reorg to match the preferred
behavior.
When rebasing internal branch on top of latest sort I noticed
few more cases that needs to get reordered.
Let's do in a bundle this time and hoping there's no other
missing places.
v2: Check for HSW/BDW ULT before generic IS_HASWELL or
IS_BROADWELL or it doesn't work as pointed by Ville.
But also ULT came afterwards anyway.
v3: Accepting suggestions from Lucas:
Sort CNL/CFL, KBL/SKL, and use <= 8 removing chv and bdw.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190301172703.12139-1-rodrigo.vivi@intel.com
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
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
I think I'm probably the one who argued in favor of having separate
implementations for both PCHs, but the calculations are actually the
same, the clocks are the same and the only difference is that on ICP
we write the numerator to the register.
I have previously suggested to kill cnp_rawclk() and keep the
icp_rawclk() style, but Ville gave some good arguments that what's in
this patch may be the better choice.
v2: Switch numerator to 1 from 1000 and adjust calculations
accordingly (Ville).
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-3-paulo.r.zanoni@intel.com
Although CNP names this field "Counter Fraction", what we write to the
register is really the denominator for the fractional part of the
divider, not the fractional part (and the field description even says
that). The ICP spec renamed the field to "Counter Fraction
Denominator", which makes a lot more sense. Use the more complete ICL
naming because we will merge the CNP and ICP functions into a single
one, which will introduce the concept of the numerator. That will make
a lot more sense when you read the "num/frac = den" calculation.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-2-paulo.r.zanoni@intel.com
BSpec was updated and now there's no more "subtract 1" to the
Microsecond Counter Divider field.
It seems this should help fixing some GMBUS issues. I'm not aware of
any specific open bug that could be solved by this patch.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181112232313.26373-1-paulo.r.zanoni@intel.com
While checking the opportunity to add a display_gen
check to allow glk and cnl to be on same bucket I noticed
these FIXME cases here.
So I got the confirmation from HW architect that we actually
never needed this workaround.
"GLK supports 2 pixel per clock, so pixel clock can be up to 2 * cdclk."
So, this reverts commit 97f55ca5b6 ("drm/i915/glk: limit pixel
clock to 99% of cdclk workaround")
Fixes: 97f55ca5b6 ("drm/i915/glk: limit pixel clock to 99% of cdclk workaround")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Madhav Chauhan <madhav.chauhan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Clinton Taylor <clinton.a.taylor@intel.com>
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181026005636.22274-1-rodrigo.vivi@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
ICL DVFS is almost the same as CNL, except for the CDCLK/DDICLK
table. Implement it just like CNL does.
References: commit 48469eced2 ("drm/i915: Use cdclk_state->voltage
on CNL")
References: commit 53e9bf5e81 ("drm/i915: Adjust system agent
voltage on CNL if required by DDI ports")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180614221018.19044-1-paulo.r.zanoni@intel.com
While checking workarounds related to the CDCLK PLL, I noticed that the
DMC firmware bits for WA#1183 are missing for SKL. After that I
clarified with HW people that it's not needed on SKL, since it doesn't
support eDP1.4 which would be the only thing requiring the problematic
CDCLK clock rates. So in theory we shouldn't ever choose these
frequencies, but add an assert in any case for catching such cases and
for documentation.
v2:
- Move the check to skl_set_cdclk and warn whenever using the
corresponding VCO freq. (Ville)
v3:
- Actually check for the platform. (Ville)
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/20180608144137.7943-1-imre.deak@intel.com
On intel_dp_compute_config() we were calculating the needed vco
for eDP on gen9 and we stashing it in
intel_atomic_state.cdclk.logical.vco
However few moments later on intel_modeset_checks() we fully
replace entire intel_atomic_state.cdclk.logical with
dev_priv->cdclk.logical fully overwriting the logical desired
vco for eDP on gen9.
So, with wrong VCO value we end up with wrong desired cdclk, but
also it will raise a lot of WARNs: On gen9, when we read
CDCLK_CTL to verify if we configured properly the desired
frequency the CD Frequency Select bits [27:26] == 10b can mean
337.5 or 308.57 MHz depending on the VCO. So if we have wrong
VCO value stashed we will believe the frequency selection didn't
stick and start to raise WARNs of cdclk mismatch.
[ 42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 42.897269] cdclk state doesn't match!
[ 42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
[ 43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
v2: Move the entire eDP's vco logical adjustment to inside
the skl_modeset_calc_cdclk as suggested by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: bb0f4aab0e ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com
In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.
Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.
The proper fix would be to increase CDCLK dynamically from the audio
component hooks.
v2:
- Address comment (Jani)
- New design approach
v3: - Typo fix on top of v1
v4 by Jani: rewrite commit message, add comment in code
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Cc: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
(cherry picked from commit 2a5b95b448)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Pull trivial tree updates from Jiri Kosina.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
kfifo: fix inaccurate comment
tools/thermal: tmon: fix for segfault
net: Spelling s/stucture/structure/
edd: don't spam log if no EDD information is present
Documentation: Fix early-microcode.txt references after file rename
tracing: Block comments should align the * on each line
treewide: Fix typos in printk
GenWQE: Fix a typo in two comments
treewide: Align function definition open/close braces
This patch fixes spelling typos found in printk.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.
After looking at drm.debug output I noticed that initially we inherit the
cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 333333 KHz makes the problem go away.
I've tested this on various Bay Trail devices, to make sure this not does
cause regressions on other devices and the higher cdclk does not cause
any problems on the following devices:
-GP-electronic T701 1024x600 333333 KHz cdclk after this patch
-PEAQ C1010 1920x1200 333333 KHz cdclk after this patch
-PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch
-Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch
Also interesting wrt this is the comment in vlv_calc_cdclk about the
existing workaround to avoid 200 Mhz as clock because that causes issues
in some cases.
This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI
panel is active.
Changes in v2:
-Change the commit message and the code comment to not treat the GOP as
a reference, the GOP should not be treated as a reference
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220105017.11259-1-hdegoede@redhat.com
(cherry picked from commit c8dae55a8c)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.
v2:
- Implement the voltage levels.
- Rebase.
v3:
- Adjust to the new "bypass" clock (Imre).
- Call intel_dump_cdclk_state() too.
- Rename a variable to avoid confusion.
- Simplify the DVFS part.
v4:
- Remove wrong bit definition (James).
- Also drive-by fix the coding style for the register definition we
touched.
v5:
- Comment style (checkpatch).
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206193346.18272-1-paulo.r.zanoni@intel.com
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.
Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)
This issue is similar to
commit 2c7d0602c8 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.
v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.4+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
(cherry picked from commit e76019a819)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
There is no requirement for doing the PCODE request polling atomically,
so do that only for a short time switching to sleeping poll afterwards.
The specification requires a 150usec timeout for the change notification,
so let's use that for the atomic poll. Do the extra 2ms poll - needed as
a workaround on BXT/GLK - in sleeping mode.
v2:
- rebase on v2 of patchset dropping the sandybridge_pcode_read/write
refactoring (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
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/20180130142939.17983-2-imre.deak@intel.com
Currently we see sporadic timeouts during CDCLK changing both on BXT and
GLK as reported by the Bugzilla: ticket. It's easy to reproduce this by
changing the frequency in a tight loop after blanking the display. The
upper bound for the completion time is 800us based on my tests, so
increase it from the current 500us to 2ms; with that I couldn't trigger
the problem either on BXT or GLK.
Note that timeouts happened during both the change notification and the
voltage level setting PCODE request. (For the latter one BSpec doesn't
require us to wait for completion before further HW programming.)
This issue is similar to
commit 2c7d0602c8 ("drm/i915/gen9: Fix PCODE polling during CDCLK
change notification")
but there the PCODE request does complete (as shown by the mbox
busy flag), only the reply we get from PCODE indicates a failure.
So there we keep resending the request until a success reply, here we
just have to increase the timeout for the one PCODE request we send.
v2:
- s/snb_pcode_request/sandybridge_pcode_write_timeout/ (Ville)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.4+
Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103326
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180130142939.17983-1-imre.deak@intel.com
Add register definitions for setting the rawclock.
Set the numerator,denominator and divider values.
v2: Simplify the commit message. Simplify the math.
Add register bits for numerator. (Paulo)
v3 (from Paulo): coding style bikesheds.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180111180010.24357-5-paulo.r.zanoni@intel.com
The CDCLK bypass frequency can vary on upcoming platforms, so prepare
for that now by tracking its value in the CDCLK state.
Currently on BDW+ the bypass frequency is always the reference clock and
I didn't bother with earlier platforms since it's not all that clear
what's the bypass clock on those.
I also didn't bother adding support for changing this frequency, since
atm I don't see any need for it.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.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/20180117172508.15993-1-imre.deak@intel.com
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJaW+iVAAoJEHm+PkMAQRiGCDsIAJALNpX7odTx/8y+yCSWbpBH
E57iwr4rmnI6tXJY6gqBUWTYnjAcf4b8IsHGCO6q3WIE3l/kt+m3eA21a32mF2Db
/bfPGTOWu5LoOnFqzgH2kiFuC3Y474toxpld2YtkQWYxi5W7SUtIHi/jGgkUprth
g15yPfwYgotJd/gpmPfBDMPlYDYvLlnPYbTG6ZWdMbg39m2RF2m0BdQ6aBFLHvbJ
IN0tjCM6hrLFBP0+6Zn60pevUW9/AFYotZn2ankNTk5QVCQm14rgQIP+Pfoa5WpE
I25r0DbkG2jKJCq+tlgIJjxHKD37GEDMc4T8/5Y8CNNeT9Q8si9EWvznjaAPazw=
=o5gx
-----END PGP SIGNATURE-----
BackMerge tag 'v4.15-rc8' into drm-next
Linux 4.15-rc8
Daniel requested this for so the intel CI won't fall over on drm-next
so often.
Display WA #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
(cherry picked from commit 53421c2fe9)
[ Lucas: Backport to 4.15 adding back variable that has been removed on
commits not meant to be backported ]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180102201837.6812-1-lucas.demarchi@intel.com
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.
After looking at drm.debug output I noticed that initially we inherit the
cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 333333 KHz makes the problem go away.
I've tested this on various Bay Trail devices, to make sure this not does
cause regressions on other devices and the higher cdclk does not cause
any problems on the following devices:
-GP-electronic T701 1024x600 333333 KHz cdclk after this patch
-PEAQ C1010 1920x1200 333333 KHz cdclk after this patch
-PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch
-Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch
Also interesting wrt this is the comment in vlv_calc_cdclk about the
existing workaround to avoid 200 Mhz as clock because that causes issues
in some cases.
This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI
panel is active.
Changes in v2:
-Change the commit message and the code comment to not treat the GOP as
a reference, the GOP should not be treated as a reference
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220105017.11259-1-hdegoede@redhat.com
Display WA #1183 was recently added to workaround
"Failures when enabling DPLL0 with eDP link rate 2.16
or 4.32 GHz and CD clock frequency 308.57 or 617.14 MHz
(CDCLK_CTL CD Frequency Select 10b or 11b) used in this
enabling or in previous enabling."
This workaround was designed to minimize the impact only
to save the bad case with that link rates. But HW engineers
indicated that it should be safe to apply broadly, although
they were expecting the DPLL0 link rate to be unchanged on
runtime.
We need to cover 2 cases: when we are in fact enabling DPLL0
and when we are just changing the frequency with small
differences.
This is based on previous patch by Rodrigo Vivi with suggestions
from Ville Syrjälä.
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171204232210.4958-1-lucas.demarchi@intel.com
ips_enabled was used as a variable of whether IPS can be enabled or not,
but should be used to test whether IPS is actually enabled.
Changes since v1:
- Call needs_modeset on new crtc state. (Ville)
- IPS can be enabled with sprite plane enabled too. (Ville)
- Fix CDCLK vs IPS workaround. (Ville)
Changes since v2:
- Only re-enable fastset when inheriting mode. (Ville)
- Put the conditions for enabling and disabling IPS in a helper.
Changes since v3:
- Keep the max_cdclk workaround working. (Ville)
- Also check logical cdclk out of paranoia.
- Remove planes check from IPS disable function for initial disable.
- Remove assert_plane_enabled/disabled checks and use
crtc_state->active_planes for hsw_enable_ips only, always allow
calling hsw_disable_ips to disable it initially in hw.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171122183901.47720-1-maarten.lankhorst@linux.intel.com
[mlankhorst: pipe_config -> crtc_state (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
This is heavily based on a initial patch provided by Ville
plus all changes provided later by Ander.
As Geminilake, Cannonlake also supports 2 pixels per clock.
Different from Geminilake we are not implementing the 99% Wa.
But we can revisit that decision later if we find out
any limitation on later CNL SKUs.
v2: Rebase on top of commit 'd305e0614601 ("drm/i915: Track
minimum acceptable cdclk instead of "minimum dotclock")'
v3: When fixing HDMI on CNL I noticed that I missed to convert
back the doubled pixel rate to cdclk.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003223142.26264-1-rodrigo.vivi@intel.com
WARN if the cdclk state doesn't match what we expect after programming.
And let's remove the WARN from bdw_set_cdclk() that's trying to achieve
the same thing in a more limite fashion.
Also take the opportunity to refactor the code to use a common function
for dumping out a cdclk state.
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-11-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
chv_set_cdclk() sanity checks that the cdclk frequency is one of the
legal values. Do the same in the VLV function.
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-10-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
On CNL we may need to bump up the system agent voltage not only due
to CDCLK but also when driving DDI port with a sufficiently high clock.
To that end start tracking the minimum acceptable voltage for each crtc.
We do the tracking via crtcs because we don't have any kind of encoder
state. Also there's no downside to doing it this way, and it matches how
we track cdclk requirements on account of pixel rate.
v2: Allow disabled crtcs to use the min voltage
Add IS_CNL check to intel_ddi_compute_min_voltage() since
we're using CNL specific values there
s/intel_compute_min_voltage/cnl_compute_min_voltage/ since
the function makes hw specific assumptions about the voltage
values
v3: Drop the test hack leftovers from skl_modeset_calc_cdclk()
v4: s/voltage/voltage_level/ (Rodrigo)
Replace DPLL DVFS FIXMEs with an explanation why we don't
do anything there (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-9-ville.syrjala@linux.intel.com
Track the system agent voltage we request from pcode in the cdclk state
on CNL. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.
v2: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-8-ville.syrjala@linux.intel.com
Track the system agent voltage we request from pcode in the cdclk state
on BXT/GLK. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.
v2: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-7-ville.syrjala@linux.intel.com
Track the system agent voltage we request from pcode in the cdclk state
on SKL/KBL/CFL. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.
v2: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-6-ville.syrjala@linux.intel.com
Track the system agent voltage we request from pcode in the cdclk state
on BDW. Annoyingly we can't actually read out the current value since
there's no pcode command to do that, so we'll have to just assume that
it worked.
v2: Keep the WARN_ON (Rodrigo)
v3: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-5-ville.syrjala@linux.intel.com
Store the punit DSPFREQUAR value into cdclk_state->voltage on
VLV/CHV. Since we can actually read that out from the hardware
this can give us a bit more cross checking between the hardware
and software state.
v2: Don't break waiting for cdclk change on VLV/CHV
v3: Split out the cdclk sanity check in vlv_set_cdclk() (Rodrigo)
v4: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-4-ville.syrjala@linux.intel.com
For CNL we'll need to start considering the port clocks when we select
the voltage level for the system agent. To that end start tracking the
voltage in the cdclk state (since that already has to adjust it).
v2: s/voltage/voltage_level/ (Rodrigo)
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com
Redo some switch statements in the cdclk code to use a common
fall through for the default case. Makes everything look a bit
more uniform
Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-2-ville.syrjala@linux.intel.com
In order to separate GT PM related functionality into new structure
we are updating rps structure. hw_lock in it is used for display
related PCU communication too hence move it to dev_priv.
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1507360055-19948-8-git-send-email-sagar.a.kamble@intel.com
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010213010.7415-7-chris@chris-wilson.co.uk
During IGT testing it has been shown that the specification
defined polling time of 1 us for FCLK_DONE, is sometimes not
enough. The issue is still reproducible while disabling
C-states through the PM QoS framework and also while disabling
preemtion. From this the most plausible explanation is that the
issue is due to a firmware flaw.
As a workaround, it is better to wait a little bit longer for
the FCLK_DONE to come around, than to leave with an DRM_ERROR
and having FCLK_DONE at a randome time after.
While spinning a list of igt tests prone to reproduce the issue
the FCLK_DONE poll failed at approximately 2% of the invocations
of the bdw_set_cdclk function. The longest poll time during this
testing was measured to ~7us. So, the suggested new poll time of
100us is on the safe side.
v2: Added more documentation about investigations done.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102243
Signed-off-by: Marta Lofstedt <marta.lofstedt@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170908132829.6312-1-marta.lofstedt@intel.com
Currently the .modeset_calc_cdclk() hooks check the final cdclk value
against the max allowed. That's not really sufficient since the low
level calc_cdclk() functions effectively clamp the minimum required
cdclk to the max supported by the platform. Hence if the minimum
required exceeds the platforms capabilities we'd keep going anyway
using the max cdclk frequency.
To fix that let's move the check earlier into
intel_crtc_compute_min_cdclk() and we'll check the minimum required
cdclk of the pipe against the maximum supported by the platform.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170710193347.8734-2-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Make the min_pixclk thing less confusing by changing it to track
the minimum acceptable cdclk frequency instead. This means moving
the application of the guardbands to a slightly higher level from
the low level platform specific calc_cdclk() functions.
The immediate benefit is elimination of the confusing 2x factors
on GLK/CNL+ in the audio workarounds (which stems from the fact
that the pipes produce two pixels per clock).
v2: Keep cdclk higher on CNL to workaround missing DDI clock voltage handling
v3: Squash with the CNL cdclk limits patch (DK)
v4: s/intel_min_cdclk/intel_pixel_rate_to_cdclk/ (DK)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170830185703.8189-1-ville.syrjala@linux.intel.com
There are still cases on these platforms where an attempt is made to
configure the CDCLK while the power domain is off, like when coming back
from a suspend. So the workaround below is still needed.
This effectively reverts commit 63ff304425 ("drm/i915: Nuke the
VLV/CHV PFI programming power domain workaround").
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101517
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gabriel Krisman Bertazi <krisman@collabora.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628210605.4994-1-krisman@collabora.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
