So I've sent the first pull request to Dave and I expect his request
for a merge tree any second now ;-)
More seriously I have some pending patches for 3.19 that depend upon
both trees, hence backmerge. Conflicts are all trivial.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
drivers/gpu/drm/i915/intel_display.c
v2: Of course I've forgotten the fixup script for the silent conflict.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Fix short vs. long hpd detection for non-g4x and non-pch split
platforms.
Broken since introduction in
commit 13cf550448
Author: Dave Airlie <airlied@redhat.com>
Date: Wed Jun 18 11:29:35 2014 +1000
drm/i915: rework digital port IRQ handling (v2)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83175
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
On CHV the display DDC pins may be muxed to an alternate function if
there's no need for DDC on a specific port, which is the case for eDP
ports since there's no way to plug in a DP++ HDMI dongle.
This causes problems when trying to determine if the port is present
since the the DP_DETECTED bit is the latched state of the DDC SDA pin
at boot. If the DDC pins are muxed to an alternate function the bit
may indicate that the port isn't present.
To work around this look at the VBT as well as the DP_DETECTED bit
to determine if we should attempt registering an eDP port. Do this
only for ports B and C since port D doesn't support eDP (no PPS/BLC).
In theory someone could also wire up a normal DP port w/o DDC lines.
That would just mean that simple DP++ HDMI dongles wouldn't work
on such a port. With this change we would still fail to register
such DP ports. But let's hope no one wires their board in such a way,
and if they do we can extend the VBT checks to cover normal DP ports
as well.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84265
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We were missing the pipe B/C vblank bits! Take a look at
gen8_de_irq_postinstall for a comparison.
This should fix a bunch of IGT tests.
There are a few more things we could improve on this code, but this
should be the minimal fix to unblock us.
v2: s/extra_iir/extra_ier/ because IIR doesn't make sense (Ville)
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=83640
Testcase: igt/*
Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the duplicated DIV_ROUND_CLOSEST_ULL macro into the intel_drv.h
header file so that it can be shared between intel_display.c
and intel_panel.c.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-By: Joe Konno <joe.konno@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means a complete
solution.
TODO: Determine how best to scale "user" values to "hw" values, and
vice-versa, when the ranges are of different sizes. That would be a
buggy scenario even with this work-around.
The issue was introduced in the following (v3.17-rc1) commit:
6dda730 drm/i915: respect the VBT minimum backlight brightness
Note that for easier backporting this commit adds a duplicated macro.
A follow-up cleanup patch rectifies this for 3.18+
v2: (thanks to Chris Wilson) clarify commit message, use rounded division
macro
v3: -DIV_ROUND_CLOSEST() fails to build with CONFIG_X86_32=y. (Jani)
-Use DIV_ROUND_CLOSEST_ULL() instead. (Damien)
-v1 and v2 originally authored by Joe Konno.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Cc: stable@vger.kernel.org
Reviewed-By: Joe Konno <joe.konno@intel.com>
[danvet: Add backporting note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can use the same logic to walk the different bound/unbound lists
during shrinker (as the unbound list is a degenerate case of the bound
list), slightly compacting the code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just start with the basics for now.
Since there's a lot of different functionality in i915_irq.c I've
decided to split it into different sections and pull in just the
relevant functions. Splitting into different files looks like a lot
more work since the interrupt handlers do an awful lot of reuse all
over.
v2: Rebase onto changed function names.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's the new world order!
Not going full monty on these here and rolling this out throughout the
subsequent call chains since this is just for the kerneldoc. Later on
we can go more crazy, especially once we've embedded drm_device
correctly.
v2: Also frob the runtime_pm functions ...
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Double negations just parse harder. Also this allows us to ditch some
init code since clearing to 0 dtrt. Also ditch the assignment in
intel_pm_setup, that's not redundant since we do the assignement now
while setting up interrupts.
While at it do engage in a bit of OCD and wrap up the few lines of
setup/teardown code into little helper functions: intel_irq_fini for
cleanup and intel_irq_init_hw for hw setup.
v2: Use _install/_uninstall for the new wrapper function names as
Paulo suggested.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Clear the override bits to make sure the hardware manages
the TX FIFO reset master on its own.
v2: Squash with the earlier attempt at forcing the override bits
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The register can house two different swing marging/deemph settings at
once. However only one gets used based on some other bits. Make sure we
set those bits correctly to make the hardware use the settings we
provided.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Even though it's unliky, we should check each aux transaction not just
the first one. Also
commit ce31d9f4fc
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date: Mon Sep 29 18:29:52 2014 -0400
drm/i915: preserve other DP_TEST_SINK bits.
added a new aux transaction before the one which was checked. Fix
this.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Inspired by Ville constifying the send buffer for pach_aux.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Use pack_aux() to construct the PSR exit DPMS D0 AUX message,
and use the defines from dp_dp_helper.h to populate the message
contents.
v2: Use sizeof() for message size (Jani)
Use a generic loop to write EDP_PSR_AUX_DATA registers
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This seems to have been accidentally lost in
commit be62acb4cc
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Fri Aug 30 16:19:28 2013 +0300
drm/i915: ban badly behaving contexts
Without this real gpu hangs only log output at info level, which gets
filtered away by piglit's testrunner.
v2: Tune down to notice level. Note that we need to add drm/i915 so
that at least the automatic igt dmesg filtering still picks it up.
v3: git add and lack of coffee don't mix well.
v4: Message is in between hw and sw reset, so switch verb to
continuous form.
v5: Use i915_stop_rings_allow_warn for consistency. For Chris' case of
injecting lots of hangs I guess we need to revamp this all anyway when
merging. For now this should plug the regression for piglit testing
mesa.
v6: Make it compile (Mika).
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
I've decided not to document the functions exported to the audio
driver since really, they shouldn't exist ...
v2: Improvements from Imre's review plus a few more spelling fixes
I've spotted.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Allows us to mark it static and so forgoe the kerneldoc for it.
Note that intel_power_domains_fini is also called from failure paths
in the driver load sequence. But the call to runtime_pm_disable for
that is harmless since by default runtime pm is already disabled.
v2: Augment the commit message as discussed with Imre on irc.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I've decided to not move intel_display_port_power_domain because
that's just a hack in our design ...
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- fini goes with init, so call it intel_power_domains_fini. While
at it shovel some of the fini code that leaked out of it back in.
- give power_enabled functions the verb _is_ to make the meaning clearer.
Also use a __ prefix instead of _unlocked to really discourage users.
- rename runtime_pm_init/fini to enable/disable since that's what they do.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Geez is the audio hack ugly.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
[danvet: Rebased on top of the skl patches.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Another layer of indirection for just an lpt-only w/a is a bit
excessive. Reduce it.
This was added in
commit 7d708ee40a
Author: Imre Deak <imre.deak@intel.com>
Date: Wed Apr 17 14:04:50 2013 +0300
drm/i915: HSW: allow PCH clock gating for suspend
Cc: Imre Deak <imre.deak@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Oh well.
v2: Fix one more spelling fail Paulo spotted.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So I think I've spotted a small gap in the frontbuffer tracking
while discussing the logic with Paulo on irc:
1. Userspace schedules gpu rendering to the current frontbuffer.
This gets tracked in dev_priv->fb_tracking.busy_bits.
2. We pageflip a fully rendered buffer before the frontbuffer
rendering completes.
3. The request retiring will never clear busy_bits (since at retire
time the old frontbuffer won't have obj->frontbuffer_bits set), so
these bits now are stuck until someone again does a bit of frontbuffer
tracking.
If we clear stale busy_bits in flip_prepare this gap is closed.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Haswell and later silicon has added a new pixel replication register
to the pipe timings for each transcoder. Now in addition to the
DPLL_A_MD register for the pixel clock double, we also need to write
to the TRANS_MULT_n (0x6002c) register to double the pixel data. Writing
to the DPLL only double the pixel clock.
ver2: Macro name change from MULTIPLY to PIPE_MULTI. (Daniel)
ver3: Do not set pixel multiplier if transcoder is eDP (Ville)
ver4: Macro name change to PIPE_MULT and default else pixel_multiplier
Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Appease checkpatch and move one hunk back into the right
place that git am misplace!?]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL stage 1 patches still need polish so will likely miss the 3.18
merge window. We've decided to postpone to 3.19 so let's pull this in
to make patch merging and conflict handling easier.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Sink crc was implemented based on dp 1.1 spec that had all TEST_SINK bits
reserved reading all 0s. But when reviewing my latest changes on sink crc
Todd warned me that on new specs we have other valid bits on this reg that we
might want to preserve.
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It will be usefull to specify w/a that affects only BDW GT3.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases like when PSR just got enabled the panel need more vblank
times to calculate CRC. I figured that out with the new PSR test cases
facing some cases that I had a green screen but a blank CRC. Even with
2 vblank waits on kernel + 2 vblank waits on test case.
So let's give up to 6 vblank wait time. However we now check for
TEST_CRC_COUNT that shows when panel finished to calculate CRC and
has it ready.
v2: Jani pointed out attempts decrements was wrong and should never reach
the error condition. And Daniel pointed out that EIO is more appropriated than
EGAIN. Also I realized that I have to read test_crc_count after setting
test_sink
v3: Rebase and adding error message
Cc: Todd Previte <tprevite@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the GPU frequency isn't going to change don't spam dmesg with
debug messages about it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
sg_alloc_table_from_pages() can build us a table with coalesced ranges which
means we need to iterate over pages and not sg table entries when releasing
page references.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Barbalho, Rafael" <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
[danvet: Remove unused local variable sg.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This reverts commit c76bb61a71.
It's apparently too broken so that Rodrigo submitted a patch to add a
config option for it. Given that the design is also ... suboptimal and
that I've only merged this to get lead engineers and managers off my
back for one second let's just revert this.
/me puts on combat gear again
It was worth a shot ...
References: http://mid.mail-archive.com/1411686380-1953-1-git-send-email-rodrigo.vivi@intel.com
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daisy Sun <daisy.sun@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
BDW display - DP buffer translation values changed to give better margin.
Further change to entry 6; set dword 0 bit 31=1.
Both changes were approved already but this one didn't landed BSpec yet
this is why it is in a separated patch. Making reviewer's life easier.
Also alowing separated tests and any future bisect that might be needed.
Reference: Predator r74080 / HSD 4394389
v2: Arthur noticed I was changing the wrong bit.
Cc: Arthur Runyan <arthur.j.runyan@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Arthur Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's make sure PSR is propperly disabled before to re-enabled it.
According to Spec, after disabled PSR CTL, the Idle state might occur
up to 24ms, that is one full frame time (1/refresh rate),
plus SRD exit training time (max of 6ms),
plus SRD aux channel handshake (max of 1.5ms).
So if something went wrong PSR will be disabled until next full
enable/disable setup.
v2: The 24ms above takes in account 16ms for refresh rate on 60Hz mode. However
on low frequency modes this can take longer. So let's use 50ms for safeness.
v3: Move wait out of psr.lock critical area.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The sw cache clean on BDW is a tempoorary workaround because we cannot
set cache clean on blt ring with risk of hungs. So we are doing the cache clean on sw.
However we are doing much more than needed. Not only when using blt ring.
So, with this extra w/a we minimize the ammount of cache cleans and call it only
on same cases that it was being called on gen7.
The traditional FBC Cache clean happens over LRI on BLT ring when there is a
frontbuffer touch happening. frontbuffer tracking set fbc_dirty variable
to let BLT flush that it must clean FBC cache.
fbc.need_sw_cache_clean works in the opposite information direction
of ring->fbc_dirty telling software on frontbuffer tracking to perform
the cache clean on sw side.
v2: Clean it a little bit and fully check for Broadwell instead of gen8.
v3: Rebase after frontbuffer organization.
v4: Wiggle confused me. So fixing v3!
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The panel has to be reconfigured only when it really loose the power.
The traditional enable/disable sequence already take care of this so we can
minimize the time spend on every re-enable.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Gen9 is different enough (for instance, fetching the memory latency
values is different from ILK+) to not take the HAS_PCH_SPLIT() branch,
so let's prefer a clean separation.
v2: Rebase on top of the broadwell_init_clock_gating() name change
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It can be handy to get the number of planes for this pipe, ie including
the primary plane to loop over them. Introduce a little function to do
so.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This can be useful to declare structures around pipes and planes and
don't have to go back auditing the code if the next platorm bump that
number.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Let's put to good use the new PLANE_CTL macros.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
SKL Uses the same hardware for all planes now, so called "universal"
planes. Ie both the primary planes and sprite planes share the same
logic. This patch implements the drm_plane vfuncs for "sprites" ie
planes that aren't the primary plane.
v2: Couple of fixes:
- Actually enabled the planes and fix the plane number
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On Skylake, we use plane1 as primary plane and plane2/3 as sprite
planes.
v2: Rebase on top of the for_each_pipe() change adding dev_priv as first
argument.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
