Changes for BXT - added a IS_BROXTON check to use the macro related to PPS
registers for BXT.
BXT does not have PP_DIV register. Making changes to handle this.
Second set of PPS registers have been defined but will be used when VBT
provides a selection between the 2 sets of registers.
v2:
[Jani] Added 2nd set of PPS registers and the macro
Jani's review comments
- remove reference in i915_suspend.c
- Use BXT PP macro
Squashing all PPS related patches into one.
v3: Jani's review comments addressed
- Use pp_ctl instead of pp
- ironlake_get_pp_control() is not required for BXT
- correct the use of && in the print statement
- drop the shift in the print statement
v4: Jani's comments
- modify ironlake_get_pp_control() - dont set unlock key for bxt
v5: Sonika's comments addressed
- check alignment
- move pp_ctrl_reg write (after ironlake_get_pp_control())
to !IS_BROXTON case.
- check before subtracting 1 for t11_t12
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We already had a few bugs in the past where FBC was compressing
nothing when it was enabled, which makes the feature quite useless.
Add this information to debugfs so the test suites can check for
regressions in this piece of the code.
Our igt/tests/kms_frontbuffer_tracking already has support for this
message.
v2: - Remove pointless VLV check (Ville).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GCP infoframes are required to inform the HDMI sink about the color
depth.
Send the GCP infoframe whenever the sink supports any deep color modes
since such sinks must anyway be capable of receiving them. For sinks
that don't support deep color let's skip the GCP in case it might
confuse the sink, although HDMI 1.4 spec does say all sinks must be
capable of reciving them. In theory we could skip the GCP infoframe
for deep color sinks in 8bpc mode as well since sinks must fall back to
8bpc whenever GCP isn't received for some time.
BSpec says we should disable GCP after disabling the port, so do that as
well.
v2: s/intel_set_gcp_infoframe/intel_hdmi_set_gcp_infoframe/
Rebased due to crtc->config changes
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflict with lack of chv phy patches and fixup typo
Chandra spotted.]
Reviewed-by: Chandra Konduru <Chandra.konduru@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
CPT/PPT require a specific procedure for enabling 12bpc HDMI. Implement
it, and to keep things neat pull the code into a function.
v2: Rebased due to crtc->config changes
s/HDMI_GC/HDMIUNIT_GC/ to match spec better
Factor out intel_enable_hdmi_audio()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-By: Chandra Konduru <Chandra.konduru@intel.com>
Testecase: igt/kms_render/*
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for changing cdclk frequency during runtime on BDW.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when computing the max pixel rate.
v2: Grab rps.hw_lock around sandybridge_pcode_write()
v3: Rebase due to power well vs. .global_resources() reordering
v4: Rebased to the latest
v5: Rebased to the latest
v6: Patch order shuffle so that Broadwell CD clock change is
applied before the patch for Haswell CD clock change
v7: Fix for patch style problems
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Implement cdclk extraction for g33, 965gm and g4x platforms. The details
came from configdb. Sadly there isn't anything there for other gen3/gen4
chipsets.
So far I've tested this on one ELK where it gave me a HPLL VCO of 5333
MHz and cdclk of 444 MHz which seems perfectly sane for this machine.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Actually read the HPLLCC register insted of assuming it's 0. Fix the
HPLLCC bit definitions and all the missing ones from the 852GME spec.
852GME, 854 and 855 all seem to match the same HPLLC encoding even
though only some of the values are valid is some of the platforms.
v2: Rebased to the latest
v3: Rebased to the latest
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Acked-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Expecting CHV power wells to be just an extended versions of the VLV
power wells, a bunch of commented out power wells were added in
anticipation when Punit folks would implement it all. Turns out they
never did, and instead CHV has fewer power wells than VLV. Rip out all
the #if 0'ed junk that's not needed.
v2: Rename the "pipe-a" well to "display" to match VLV
Clarify the pipe A power well relationship to pipes B and C (Deepak)
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not sure which LDO programming sequence delay should be used for the CHV
PHY, but the spec says that 600ns is "Used by default for initial
bringup", and the BIOS seems to use that, so let's do the same.
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GTT caching was disabled by default on gen8 due to not working with
big pages. Some information suggests that it got fixed, but still
GTT caching has been left disabled by default. Or could be it just
meant that the default was changed to off, and hence the problem
got solved.
Enable GTT caching in the hopes of some performance increase.
Whether or not the big pages issue has been fixed is irrelevant
at this stage since we don't use big pages.
This gives me a 1-2% improvement in xonotic on my BSW. Haven't tried
BDW, but supposedly it has larger TLBs so might not benefit as much.
On HSW GTT caching is enabled by default.
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>
Define a TRANS_DP_PIPE_TO_PORT() to make the CPT DP .get_hw_state()
pipe readout neater.
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>
We need to re-init the display hardware when going out of suspend. This
includes:
- Hooking the PCH to the reset logic
- Restoring CDCDLK
- Enabling the DDB power
Among those, only the CDCDLK one is a bit tricky. There's some
complexity in that:
- DPLL0 (which is the source for CDCLK) has two VCOs, each with a set
of supported frequencies. As eDP also uses DPLL0 for its link rate,
once DPLL0 is on, we restrict the possible eDP link rates the chosen
VCO.
- CDCLK also limits the bandwidth available to push pixels.
So, as a first step, this commit restore what the BIOS set, until I can
do more testing.
In case that's of interest for the reviewer, I've unit tested the
function that derives the decimal frequency field:
#include <stdio.h>
#include <stdint.h>
#include <assert.h>
#define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
static const struct dpll_freq {
unsigned int freq;
unsigned int decimal;
} freqs[] = {
{ .freq = 308570, .decimal = 0b01001100111},
{ .freq = 337500, .decimal = 0b01010100001},
{ .freq = 432000, .decimal = 0b01101011110},
{ .freq = 450000, .decimal = 0b01110000010},
{ .freq = 540000, .decimal = 0b10000110110},
{ .freq = 617140, .decimal = 0b10011010000},
{ .freq = 675000, .decimal = 0b10101000100},
};
static void intbits(unsigned int v)
{
int i;
for(i = 10; i >= 0; i--)
putchar('0' + ((v >> i) & 1));
}
static unsigned int freq_decimal(unsigned int freq /* in kHz */)
{
return (freq - 1000) / 500;
}
static void test_freq(const struct dpll_freq *entry)
{
unsigned int decimal = freq_decimal(entry->freq);
printf("freq: %d, expected: ", entry->freq);
intbits(entry->decimal);
printf(", got: ");
intbits(decimal);
putchar('\n');
assert(decimal == entry->decimal);
}
int main(int argc, char **argv)
{
int i;
for (i = 0; i < ARRAY_SIZE(freqs); i++)
test_freq(&freqs[i]);
return 0;
}
v2:
- Rebase on top of -nightly
- Use (freq - 1000) / 500 for the decimal frequency (Ville)
- Fix setting the enable bit of HSW_NDE_RSTWRN_OPT (Ville)
- Rename skl_display_{resume,suspend} to skl_{init,uninit}_cdclk to
be consistent with the BXT code (Ville)
- Store boot CDCLK in ddi_pll_init (Ville)
- Merge dev_priv's skl_boot_cdclk into cdclk_freq
- Use LCPLL_PLL_LOCK instead of (1 << 30) (Ville)
- Replace various '0' by SKL_DPLL0 to be a bit more explicit that
we're programming DPLL0
- Busy poll the PCU before doing the frequency change. It takes about
3/4 cycles, each separated by 10us, to get the ACK from the CPU
(Ville)
v3:
- Restore dev_priv->skl_boot_cdclk, leaving unification with
dev_priv->cdclk_freq for a later patch (Daniel, Ville)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On B0 and C0 steppings the workaround enable bit would be overriden by
default, so the overriding must be disabled.
The WA was added in
commit 83a24979c4
Author: Nick Hoath <nicholas.hoath@intel.com>
Date: Fri Apr 10 13:12:26 2015 +0100
drm/i915/bxt: Add WaForceContextSaveRestoreNonCoherent
Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BUN 1: prop_coeff, int_coeff, tdctargetcnt programming updated and tied to
VCO frequencies. Program i_lockthresh in PORT_PLL_9.
VCO calculated based on the formula:
Desired Output = Port bit rate in MHz (DisplayPort HBR2 is 5400 MHz)
Fast Clock = Desired Output / 2
VCO = Fast Clock * P1 * P2
Prop_coeff, int_coeff, and tdctargetcnt modified according to above
calculation.
BUN 2: Port PLLs require additional programming at certain frequencies -
DCO amplitude in PORT_PLL_10
Review comments from Siva which were addressed in the initial version of the
patch.
- Change PORT_PLL_LOCK_THRESHOLD to PORT_PLL_LOCK_THRESHOLD_MASK
- Calculate for HDMI
- Correct values for vco = 5.4
- return in case of invalid vco range
v2: Imre's review comments addressed
- change dcoampovr_en to dcoampovr_en_h
- change PORT_PLL_DCO_AMP_OVR_EN to PORT_PLL_DCO_AMP_OVR_EN_H
- Correct lane stagger value for 324MHz
- Make coef common for HDMI and DP
- remove superfluous comments
v3: Imre's comments addressed
- Remove Prop_coeff, int_coeff, tdctargetcnt, dcoampovr_en, gain_ctl,
dcoampovr_en_h from bxt_clk_div and make them local variables.
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> [v1]
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Skylake nv12 format requires dbuf (aka. ddb) calculations
and programming for each of y and uv sub-planes. Made minor
changes to reuse current dbuf calculations and programming
for uv plane. i.e., with this change, existing computation
is used for either packed format or uv portion of nv12
depending on incoming format. Added new code for dbuf
computation and programming for y plane.
This patch is a pre-requisite for adding NV12 format support.
Actual nv12 support is coming in later patches.
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontaneosly during
modeset. When this happens during a modeset things go south and the
display doesn't light up.
I've managed to hit the problemn when toggling HDMI on port D on and
off. When things get corrupted the display doesn't light up, but as soon
as I manually write the correct value to the register the display comes
up.
First I was suspicious that we ourselves accidentally overwrite it with
garbage, but didn't catch anything with the reg_rw tracepoint. Also I
sprinkled check all over the modeset path to see exactly when the
corruption happens, and eg. the read back value was fine just before
intel_dp_set_m(), and corrupted immediately after it. I also made my
check function repair the register value whenever it was wrong, and with
this approach the corruption repeated several times during the modeset
operation, always seeming to trigger in the same exact calls to the
check function, while other calls to the function never caught anything.
So far I've not seen this problem occurring when carefully avoiding all
read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck
or an actual workaround, but we can hope it works. So let's avoid reading
the register and instead track the desired value of the register in dev_priv.
v2: Read out the power well state to determine initial register value
v3: Use DPIO_CHx names instead of raw numbers
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Set up the chv display PHY lane stagger registers according to
"Programming Guide for 1273 CHV eDP/DP/HDMI Display PHY" v1.04
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Robert noticed that the FF_SLICE_CS_CHICKEN2 offset was wrong. Ooops.
Ville noticed that the write was wrong since FF_SLICE_CS_CHICKEN2 is a
masked register. Re-oops.
A wonder if went through 2 people while having roughly a bug per line...
The problem was introduced in the original patch:
commit 2caa3b260a
Author: Damien Lespiau <damien.lespiau@intel.com>
Date: Mon Feb 9 19:33:20 2015 +0000
drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS
v2: Also fix the register write (Ville)
Reported-by: Robert Beckett <robert.beckett@intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Robert Beckett <robert.beckett@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Note that we also need this for skl.
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Note that we also need this for skl, requested by Imre.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Enabling BLC on BXT.
Includes register definition, and new functions for BXT.
In BXT, there are 2 sets of registers for BLC. Until there is clarity
about which set would be effective, set 1 is being used.
This would have to be re-visited if there is any change or when 2 LFPs are
enabled on BXT.
This patch enables brightness change which would be effected by use of
hot-keys or sysfs entry.
TODO:- BLC implementation will have to re-visited when
1. there is clarity about which set of registers has to be used and when.
2. CDCLK frequency is changed
v2: Jani's review comments
- Modified comment in i915_reg.h
- Renamed register defintions
- Removed definition of duty cycle max. Not required now and its not 64-bit.
v3:
- Rebase on top of VLV/CHV backlight changes, in particuliar
bxt_set_backlight() now has a different prototype (Damien)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Shankar, Uma <uma.shankar@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's keep that list sorted!
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.
v2: rename reg defn to match spec. (Ville)
v3: Updated bias setting for chv (Deepak)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch just implements the basic enable and disable
functions of DC5 state which is needed for both SKL and BXT.
Its important to load respective CSR program before calling
enable, which anyways will happen as CSR program is executed
during boot.
DC5 is a power saving state where hardware dynamically disables
power well 1 and the CDCLK PLL and saves the associated registers.
DC5 can be entered when software allows it, power well 2 is
disabled, and hardware detects that all pipes are disabled
or pipe A is enabled with PSR active.
Its better to configure display engine to have power well 2 disabled before
getting into DC5 enable function. Hence rpm framework will have to
ensure to check status of power well 2 before calling gen9_enable_dc5.
Rather dc5 entry criteria should be decided based on power well 2 status.
If disabled, then call gen9_enable_dc5.
v2: Replace HAS_ with IS_ check as per Daniel's review comments
v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register
before setting them as per Satheesh's review comments.
v4: call POSTING_READ for every write to a register to ensure that
its written immediately.
v5: Modified as per review comments from Imre.
- Squashed register definitions into this patch.
- Finetuned comments and functions.
v6:
Avoid redundant writes in gen9_set_dc_state_debugmask_memory_up function.
v7:
- Rebase to latest.
- Move all runtime PM functions defined in intel_display.c to
intel_runtime_pm.c.
v8: Rebased to drm-intel-nightly. (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm-intel-next-2015-04-23:
- dither support for ns2501 dvo (Thomas Richter)
- some polish for the gtt code and fixes to finally enable the cmd parser on hsw
- first pile of bxt stage 1 enabling (too many different people to list ...)
- more psr fixes from Rodrigo
- skl rotation support from Chandra
- more atomic work from Ander and Matt
- pile of cleanups and micro-ops for execlist from Chris
drm-intel-next-2015-04-10:
- cdclk handling cleanup and fixes from Ville
- more prep patches for olr removal from John Harrison
- gmbus pin naming rework from Jani (prep for bxt)
- remove ->new_config from Ander (more atomic conversion work)
- rps (boost) tuning and unification with byt/bsw from Chris
- cmd parser batch bool tuning from Chris
- gen8 dynamic pte allocation (Michel Thierry, based on work from Ben Widawsky)
- execlist tuning (not yet all of it) from Chris
- add drm_plane_from_index (Chandra)
- various small things all over
* tag 'drm-intel-next-2015-04-23-fixed' of git://anongit.freedesktop.org/drm-intel: (204 commits)
drm/i915/gtt: Allocate va range only if vma is not bound
drm/i915: Enable cmd parser to do secure batch promotion for aliasing ppgtt
drm/i915: fix intel_prepare_ddi
drm/i915: factor out ddi_get_encoder_port
drm/i915/hdmi: check port in ibx_infoframe_enabled
drm/i915/hdmi: fix vlv infoframe port check
drm/i915: Silence compiler warning in dvo
drm/i915: Update DRIVER_DATE to 20150423
drm/i915: Enable dithering on NatSemi DVO2501 for Fujitsu S6010
rm/i915: Move i915_get_ggtt_vma_pages into ggtt_bind_vma
drm/i915: Don't try to outsmart gcc in i915_gem_gtt.c
drm/i915: Unduplicate i915_ggtt_unbind/bind_vma
drm/i915: Move ppgtt_bind/unbind around
drm/i915: move i915_gem_restore_gtt_mappings around
drm/i915: Fix up the vma aliasing ppgtt binding
drm/i915: Remove misleading comment around bind_to_vm
drm/i915: Don't use atomics for pg_dirty_rings
drm/i915: Don't look at pg_dirty_rings for aliasing ppgtt
drm/i915/skl: Support Y tiling in MMIO flips
drm/i915: Fixup kerneldoc for struct intel_context
...
Conflicts:
drivers/gpu/drm/i915/i915_drv.c
This WA is avoid problem between shadow vs wake FIFO unload
problem during CPD/RC6 transactions on CHV.
v2: Define individual bits GTFIFOCTL (Ville)
v3: move WA to uncore_early_sanitize (ville)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[Jani: fixed some whitespace issues while applying]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The hardware, according to the specs, is limited to 256 byte transfers,
and current driver has no protections in case users attempt to do larger
transfers. The code will just stomp over status register and mayhem
ensues.
Let's split larger transfers into digestable chunks. Doing this allows
Atmel MXT driver on Pixel 1 function properly (it hasn't since commit
9d8dc3e529 "Input: atmel_mxt_ts -
implement T44 message handling" which tries to consume multiple
touchscreen/touchpad reports in a single transaction).
Cc: stable@vger.kernel.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
VSwing programming sequence as specified in the updated BXT BSpec
v2: Satheesh's review comments addressed.
- clear value before setting into registers
- move print statement to bxt function
Other changes
- since signal level will not be set into DDI_BUF_CTL, the value need
not be returned to intel_dp_set_signal_levels(). Making the bxt
specific function to return void and setting signal_levels = 0 for
bxt inside intel_dp_set_signal_levels()
- instead of signal levels, printing vswing level and pre-emphasis
level
- in case none of the pre-emphasis levels or vswing levels are set,
setting default of 400mV + 0dB
v3: Satheesh's review comments
- Check for mask before printing signal_levels.
- Removing redundant register writes
- Call intel_prepare_ddi_buffers only for HAS_PCH_SPLIT
- Making register write part generic as it will be required for HDMI as
well.
Re-structure the code to include an array for vswing related values, set
signal levels
v4: Satheesh's review comments
- Rebase over latest renaming patches
- use hsw_signal_levels for HAS_DDI
Other changes
- Modified vswing_sequence() func definition
- Rebased on top of register macro definitions
v5: Satheesh's review comments
- Check ddi translation table size
v6: Imre's review comments
- removed comments in vswing sequence
- added vswing, pre-emphasis prints in intel_dp_set_signal_levels
- added comment explaining use of DP vswing values for eDP
- initialize n_entries and ddi_transaltion table based on encoder type
- create bxt_ddi_buf_trans structure and use decimal values
- adding a flag in bxt buffer translation table to indicate def entry
v7: (imre)
- squash in Vandana's "VSwing register definition",
"HDMI VSwing programming", "Re-enable vswing programming",
"Fix vswing sequence" patches
- use BXT_PORT_* regs directly instead of via a temp var
- simplify BXT_PORT_* macro definitions
- add code comment why we read lane while write group registers
- fix readout of DP_TRAIN_PRE_EMPHASIS in debug message
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v6)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Plug bxt PLL code into existing shared DPLL framework.
v2: (imre)
- squash in Satheeshakrishna's "Define BXT clock registers" and
"Add state variables for bxt clock registers" patches
- squash in Vandanas's "Change grp access to lane access for PLL"
- fix group vs. lane access in bxt_ddi_pll_get_hw_state
- add code comment why we read from lane registers while writing to
group registers
- clean up register macros
- use BXT_PORT_PLL_* macros instead of open-coding the same
- check if BXT_PORT_PCS_DW12_LN01 matches BXT_PORT_PCS_DW12_LN23
during hardware state readout
- add missing LANESTAGGER_STRAP_OVRD masking
- add note about missing step according to the latest BUN for
PORT_PLL_9/lockthresh
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Modified as per review comments from Imre
- Mention enabling instead of allowing in the debug trace and
remove unnecessary comments.
v3:
- Rebase to latest.
- Move DC9-related functions from intel_display.c to intel_runtime_pm.c.
v4: (imre)
- remove DC5 disabling, it's a nop at this point
- squashed in Suketu's "Assert the requirements to enter or exit DC9"
patch
- remove check for RUNTIME_PM from assert_can_enable_dc9, it's not a
dependency
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com> (v3)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extend the VLV/CHV DPIO (PHY) documentation with the BXT specifics.
v2:
- add more detail about the mapping between ports and transcoders (ville)
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>
Add PHY specific display initialization sequence as per BSpec.
Note that the PHY initialization/uninitialization are done
at their current place only for simplicity, in a future patch - when more
of the runtime PM features will be enabled - these will be moved to
power well#1 and modeset encoder enabling/disabling hooks respectively.
The call to uninitialize the PHY during system/runtime suspend will be
added later in this patchset.
v1: Added function definitions in header files
v2: Imre's review comments addressed
- Moved CDCLK related definitions to i915_reg.h
- Removed defintions for CDCLK frequency
- Split uninit_cdclk() by adding a phy_uninit function
- Calculate freq and decimal based on input frequency
- Program SSA precharge based on input frequency
- Use wait_for 1ms instead 200us udelay for DE PLL locking
- Removed initial value for divider, freq, decimal, ratio.
- Replaced polling loops with wait_for
- Parameterized latency optim setting
- Fix the parts where DE PLL has to be disabled.
- Call CDCLK selection from mode set
v3: (imre)
- add note about the plan to move the cdclk/phy init to a better place
- take rps.hw_lock around pcode access
- fix DDI PHY timeout value
- squash in Vandana's "PORT_CL2CM_DW6_A BUN fix",
"DDI PHY programming register defn", "Do ddi_phy_init always",
- move PHY register macros next to the corresponding CHV/VLV macros
- move DE PLL register macros here from another patch since they are
used here first
- add BXT_ prefix to CDCLK flags
- s/COMMON_RESET/COMMON_RESET_DIS/ and clarify related code comments
- fix incorrect read value for the RMW of BXT_PHY_CTL_FAMILY_DDI
- fix using GT_DISPLAY_EDP_POWER_ON vs. GT_DISPLAY_DDI_POWER_ON
when powering on DDI ports
- fix incorrect port when setting BXT_PORT_TX_DW14_LN for DDI ports
- add missing masking when programming CDCLK_FREQ_DECIMAL
- add missing powering on for DDI-C port, rename OCL2_LDOFUSE_PWR_EN
to OCL2_LDOFUSE_PWR_DIS to reduce confusion
- add note about mismatch with bspec in the PORT_REF_DW6 fields
- factor out PHY init code to a new function, so we can call it for
PHY1 and PHY0, instead of open-coding the same
v4: (ville)
- split the CDCLK/PHY parts into two patches, update commit message
accordingly
- use the existing dpio_phy enum instead of adding a new one for the
same purpose
- flip the meaning of PHYs so that PHY_A is PHY1 and PHY_BC is PHY0 to
better match CHV
- s/BXT_PHY/_BXT_PHY/
- use _PIPE for _BXT_PHY instead of open-coding it
- drop _0_2_0_GTTMMADR suffix from BXT_P_CR_GT_DISP_PWRON
- define GT_DISPLAY_POWER_ON in a more standard way
- make a note that the CHV ConfigDB also disagrees about GRC_CODE field
definitions
- fix lane optimization refactoring fumble from v3
- add per PHY uninit functions to match the init counterparts
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
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>
Add CDCLK specific display clock initialization sequence as per BSpec.
Note that the CDCLK initialization/uninitialization are done at their
current place only for simplicity, in a future patch - when more of the
runtime PM features will be enabled - these will be moved to power
well#1 and modeset encoder enabling/disabling hooks respectively. This
also means that atm dynamic power gating power well #1 is effectively
disabled.
The call to uninitialize CDCLK during system/runtime suspend will be
added later in this patchset.
v1: Added function definitions in header files
v2: Imre's review comments addressed
- Moved CDCLK related definitions to i915_reg.h
- Removed defintions for CDCLK frequency
- Split uninit_cdclk() by adding a phy_uninit function
- Calculate freq and decimal based on input frequency
- Program SSA precharge based on input frequency
- Use wait_for 1ms instead 200us udelay for DE PLL locking
- Removed initial value for divider, freq, decimal, ratio.
- Replaced polling loops with wait_for
- Parameterized latency optim setting
- Fix the parts where DE PLL has to be disabled.
- Call CDCLK selection from mode set
v3: (imre)
- add note about the plan to move the cdclk/phy init to a better place
- take rps.hw_lock around pcode access
- move DE PLL register macros here from another patch since they are
used here first
- add BXT_ prefix to CDCLK flags
- add missing masking when programming CDCLK_FREQ_DECIMAL
v4: (ville)
- split the CDCLK/PHY parts into two patches, update commit message
accordingly
- s/DISPLAY_PCU_CONTROL/HSW_PCODE_DE_WRITE_FREQ_REQ/
- simplify BXT_DE_PLL_RATIO macros
- fix BXT_DE_PLL_RATIO_MASK
- s/bxt_select_cdclk_freq/broxton_set_cdclk_freq/
- move cdclk init/uninit/set code from intel_ddi.c to intel_display.c
- remove redundant code comments for broxton_set_cdclk_freq()
- sanitize fixed point<->integer frequency value conversion
- use DRM_ERROR instead of WARN
- do RMW when programming BXT_DE_PLL_CTL for safety
- add note about PLL lock timeout being exactly 200us
- make PCU error messages more descriptive
- instead of using 0 freq to mean PLL off/bypass freq use 19200
for clarity, as the latter one is the actual rate
- simplify pcode programming, removing duplicated
sandybridge_pcode_write() call
- sanitize code flow, remove unnecessary scratch vars in
broxton_set_cdclk() (imre)
- Remove bound check for maxmimum freq to match current code.
This check will be added later at a more proper platform
independent place once atomic support lands.
- add note to remove freq guard band which isn't needed on BXT
- add note to reduce freq to minimum if no pipe is enabled
- combine broxton_modeset_global_pipes() with
valleyview_modeset_global_pipes()
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> (v2)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This wrong logic and useless define came from first versions and
came along with all rework. Just now I notice how ugly, wrong and
useless this is.
val is already defined as 0 anyway and logic is completelly wrong
and useless. So let's starting the link_standby fix with this
cleaning.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Durgadoss R <durgadoss.r@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
GMBUS interrupt has been moved to CPU side in BXT.
What this patch does is:
1. Enable GMBUS IRQ in de_post_install function
2. Handle this interrupt as a port interrupt in display irq
handler
v2: Rebase on top of the for_each_pipe() change adding dev_priv as
first argument (Damien).
v3: read BXT_DE_PORT_GMBUS IIR flag only on BXT on other platforms
it's reserved (imre)
v4: (jani)
- remove redundant 'BXT GMBUS' comment
- fix formatting of BXT_DE_PORT_GMBUS definition
Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> (v1)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In BXT, DDI hotplug control has been moved to CPU from PCH.
This patch adds a new IRQ setup function for BXT which:
1. Checks which HPD ports are requested to be enabled by encoders.
2. Enables those ports in the hot plug control register.
3. Un-masks these port interrupts in the IMR register.
4. Enables these port interrupts in the IER register.
V3: Kept the default HPD filter count to default (500 us) as per
satheesh's comment
v4: Remove unused HPD filter defines (Damien)
v5: warn if trying to setup HPD on port A (imre)
v6: fix order of definitions for register bitfields (Daniel)
v7: (jani)
- define the size of the hpd_bxt array explicitly for bound checking
- use for_each_intel_encoder instead of open coding it
- fix format/order of definitions for BXT_HOTPLUG_CTL reg bitfields
Reviewed-by: Satheeshakrishna M <satheeshakrishna.m@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
For BXT gmbus is pulled from PCH to CPU. From implementation point of
view only pin pair configuration will change. The existing
implementation supports all platforms previous to GEN8 and also SKL. But
for BXT pin pair configuration is completely different than SKL or other
previous GEN's. This patch introduces the new pin pair configuration
structure specific to BXT and also ensures every real gmbus port has a
gpio pin.
v3 by Jani: with the platform independent prep work in place, the bxt
enabling reduces to a fairly trivial patch. Credits are due Sunil for
giving me the ideas (with his patches) what the platform independent
parts should look like.
v4: Fix intel_hdmi_init_connector() for bxt. Abstract gmbus_pin access
more. s/GPU/PCH/ in commit message.
v5: Rebase.
Issue: VIZ-3574
Signed-off-by: A.Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Separate topic branch for bxt didn't work out since we needed to
refactor the gmbus code a bit to make it look decent. So backmerge.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Set TLBPF in TILECTL. This fixes an issue with BXT HW seeing
corrupted pte entries.
v2:
- move the workaround to bxt_init_clock_gating (imre)
Signed-off-by: Robert Beckett <robert.beckett@intel.com> (v1)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Nick Hoath <nicholas.hoath@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: Moving creation of property in a function, checking for 90/270
rotation simultaneously (Chris)
Letting primary plane to be positioned
v3: Adding if/else for 90/270 and rest params programming, adding check for
pixel_format, some cleanup (review comments)
v4: Adding right pixel_formats, using src_* params instead of crtc_* for offset
and size programming (Ville)
v5: Rebased on -nightly and Tvrtko's series for gtt remapping.
v6: Rebased on -nightly (Tvrtko's series merged)
v7: Moving pixel_format check to intel_atomic_plane_check (Matt)
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reuse the same reclocking strategy for Baytail as on its bigger brethren,
Sandybridge and Ivybridge. In particular, this makes the device quicker
to reclock (both up and down) though the tendency now is to downclock
more aggressively to compensate for the RPS boosts.
v2: Rebase
v3: Exclude Cherrytrail as Deepak was concerned that the increased
number of register writes would wake the common powerwell too often.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Deepak S <deepak.s@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Modify the Gen9 SSEU device status logic to support Broxton.
Broxton reuses the Skylake power gate acknowledgment registers but
has at most 1 slice and 3 subslices. Broxton supports subslice
power gating within its single slice.
Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
