| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Fill in driver type, hsync, vrefresh and name.
Those members are not read out but can be calculated from the mode.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Updated the HAS_CORE_RING_FREQ macro to add the broxton check,
so as to disallow the programming & read of ring frequency
table for it.
Issue: VIZ-5144
Suggested-by: Daniel Vetter <[email protected]>
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Added a new HAS_CORE_RING_FREQ macro, currently used in
gen6_update_ring_freq & i915_ring_freq_table debugfs function.
The programming & read of ring frequency table is needed for newer
GEN(>=6) platforms, except VLV/CHV.
Issue: VIZ-5144
Suggested-by: Daniel Vetter <[email protected]>
Signed-off-by: Akash Goel <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Calculate all state using a normal transition, but afterwards fudge
crtc->state->active back to its old value. This should still allow
state restore in setup_hw_state to work properly.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
And get rid of things that are no longer true. This function is only
used for forcing a modeset when encoder properties are changed.
Because this is not yet done atomically, assume a full modeset is
needed and force a modeset on the crtc.
Changes since v1:
- s/reset/force modeset/
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This allows us to get rid of the set_init_power in
modeset_update_crtc_domains. The state should be sanitized enough
after setup_hw_state to not need the init power.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The previous commit converted hw readout to atomic, all the new_*
members were used for restoring the old state, but with the
conversion of suspend to atomic there's no use left for them.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Instead of all the ad-hoc updating, duplicate the old state first
before reading out the hw state, then restore it.
intel_display_resume is a new function that duplicates the sw state,
then reads out the hw state, and commits the old state.
intel_display_setup_hw_state now only reads out the atomic state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
drm/i915: Readout initial hw mode, v2.
Atomic requires a mode blob when crtc_state->enable is true, or
you get a huge warn_on.
With a few tweaks the mode we read out from hardware could be used
as the real mode without a modeset, but this requires too much
testing, so for now force a modeset the first time the mode blob's
updated.
This preserves the old behavior, because previously we never set
the initial mode, which always meant that a modeset happened
when the mode was first set.
Changes since v1:
- Add a description in intel_modeset_readout_hw_state of how the
recalculation is done.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This is required to properly initialize vblanks on the active crtc.
Without it drm_calc_vbltimestamp_from_scanoutpos can fail with
crtc 0: Noop due to uninitialized mode.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property.
If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Unreference the old mode_blob by calling the crtc_destroy_state
helper before zeroing the crtc_state.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
All non-primary planes get disabled during hw readout,
this reduces complexity and means not having to do some plane
visibility checks during the first commit.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This change adds the programming of the MOCS registers to the gen 9+
platforms. The set of MOCS configuration entries introduced by this
patch is intended to be minimal but sufficient to cover the needs of
current userspace - i.e. a good set of defaults. It is expected to be
extended in the future to provide further default values or to allow
userspace to redefine its private MOCS tables based on its demand for
additional caching configurations. In this setup, userspace should
only utilize the first N entries, higher entries are reserved for
future use.
It creates a fixed register set that is programmed across the different
engines so that all engines have the same table. This is done as the
main RCS context only holds the registers for itself and the shared
L3 values. By trying to keep the registers consistent across the
different engines it should make the programming for the registers
consistent.
v2:
-'static const' for private data structures and style changes.(Matt Turner)
v3:
- Make the tables "slightly" more readable. (Damien Lespiau)
- Updated tables fix performance regression.
v4:
- Code formatting. (Chris Wilson)
- re-privatised mocs code. (Daniel Vetter)
v5:
- Changed the name of a function. (Chris Wilson)
v6:
- re-based
- Added Mesa table entry (skylake & broxton) (Francisco Jerez)
- Tidied up the readability defines (Francisco Jerez)
- NUMBER of entries defines wrong. (Jim Bish)
- Added comments to clear up the meaning of the tables (Jim Bish)
Signed-off-by: Peter Antoine <[email protected]>
v7 (Francisco Jerez):
- Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
tables. Prefix L3-specific defines consistently with L3_ and
e/LLC-specific defines with LE_ to avoid this kind of confusion in
the future.
- Change L3CC WT define back to RESERVED (matches my hardware
documentation and the original patch, probably a misunderstanding
of my own previous comment).
- Drop Android tables, define new minimal tables more suitable for the
open source stack.
- Add comment that the MOCS tables are part of the kernel ABI.
- Move intel_logical_ring_begin() and _advance() calls one level down
(Chris Wilson).
- Minor formatting and style fixes.
v8 (Francisco Jerez):
- Add table size sanity check to emit_mocs_control/l3cc_table() (Chris
Wilson).
- Add comment about undefined entries being implicitly set to uncached
for forwards compatibility.
v9 (Francisco Jerez):
- Minor style fixes.
Signed-off-by: Francisco Jerez <[email protected]>
Acked-by: Damien Lespiau <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Totatlly forgotten that we have these when nuking all the UMS code.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Nothing depends on this outside initial hw readout, so keep this
struct on the stack instead.
Changes since v1:
- Remove unrelated changes.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The src and crtc rectangles were never set, resulting in the primary
plane being made invisible on first atomic update.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Instead of doing ad-hoc checks we already have a way of checking
if the state is compatible or not. Use this to force a modeset.
Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE
we should check if a full modeset is really needed.
Fastboot will allow the adjust parameter to ignore some stuff
too, and it will fix up differences in state that are ignored
by the compare function.
Changes since v1:
- Increase the value of the lowest m/n to prevent truncation.
- Dump pipe config when fastboot's used, without a modeset.
- Add adjust parameter to intel_compare_link_m_n, which is
used to adjust m2_n2 if it's a multiple of m_n.
- Add exact parameter intel_compare_m_n.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Use the atomic state instead, this allows removing plane_config
from the crtc after the full hw readout is completed.
The size can be found in the fb, no need for the plane_config.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
There's not much point for calculating the changes for the old
state. Instead just disable all scalers when disabling. It's
probably good enough to just disable the crtc_scaler, but just in
case there's a bug disable all scalers.
This means intel_atomic_setup_scalers is only called in the crtc
check function now, so all the transitional code can be removed.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This is probably hard to hit right now because in most cases all
atomic locks are taken, but after conversion to atomic this will make
it more likely to corrupt the crtc->config pointer, resulting in hard
to find bugs.
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Ring frequency table programming is not required on BXT. Added separate
checks to enable the programming only for SKL & skip for BXT.
v2: Removed the BXT check from gen6_update_ring_freq function
Issue: VIZ-5144
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Watermark calculations depend on the intel_crtc->active flag to be set
properly. Suspend/resume is broken on SKL and we also get DDB mismatches
without this patch.
The regression was introduced in:
commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6
Author: Maarten Lankhorst <[email protected]>
Date: Mon Jun 15 12:33:53 2015 +0200
drm/i915: Update less state during modeset.
No need to repeatedly call update_watermarks, or update_fbc.
Down to a single call to update_watermarks in .crtc_enable
Signed-off-by: Maarten Lankhorst <[email protected]>
Reviewed-by: Matt Roper <[email protected]>
Tested-by(IVB): Matt Roper <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
v2: Don't touch disable_shared_dpll()
Signed-off-by: Patrik Jakobsson <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91203
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Currently we update the freq before masking the interrupts, which can
allow new interrupts to occur before the frequency has changed. These
extra interrupts might waste some cpu cycles. This patch corrects
this by masking interrupts prior to updating the frequency.
Note from Chris:
"Well it won't waste CPU cycles as the interrupt is also masked by the
threshold limits, but there should be no harm at all in reordering the
patch so, and it does make a certain amount of sense."
Signed-off-by: Deepak S <[email protected]>
Signed-off-by: Praveen Paneri <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
[danvet: Add note from Chris.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Update the hotplug documentation to explain that hotplug storm
is not expected for Display port panels and hence is not handled
in current code.
v2: update the statements as recommended by Daniel
Signed-off-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since
commit e62925567c7926e78bc8ca976cde5c28ea265a49
Author: Vandana Kannan <[email protected]>
Date: Wed Jul 1 17:02:57 2015 +0530
drm/i915/bxt: BUNs related to port PLL
BXT DPLL can now generate frequencies in the 216-223 MHz range.
Adjust the HDMI port clock checks to account for the reduced range
of invalid frequencies.
Cc: Vandana Kannan <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We do the exact same steps around the disp2d/pipe A power well
enable/disable on VLV and CHV. Refactor the shared code into
some helpers.
Note that this means we now call vlv_power_sequencer_reset() before
turning off the power well, whereas before we did it after. That
doesn't matter though since vlv_power_sequencer_reset() just resets
the power sequencer software tracking and doesn't touch the hardware
at all.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The pipe A power well is the "disp2d" well on CHV and pipe B and C wells
don't even exist. Thereforce we can remove the checks for pipe A vs.
others and just assume it's always pipe A.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Drop the spurious 'A' from the VLV/CHV ref clock enable define,
and add the "REF" to the VLV ref clock selection bit. Also
s/CLOCK/CLK/ for extra consistency.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
We disable the DPLL VGA mode when enabling the DPLL, but we enaable it
again when disabling the DPLL. Having VGA mode enabled even in unused
DPLLs can cause problems for CHV, so it seems wiser to always keep it
disabled. And let's just do that on all GMCH platforms to keep things
as similar as possible between them.
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Sivakumar Thulasimani <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Updated the i915_ring_freq_table debugfs function to support the read
of ring frequency table, through Punit interface, for SKL also.
Issue: VIZ-5144
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Ring frequency table programming changes for SKL. No need for a
floor on ring frequency, as the issue of performance impact with
ring running below DDR frequency, is believed to be fixed on SKL
v2: Removed the check for avoiding ring frequency programming for BXT (Rodrigo)
Issue: VIZ-5144
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Read the efficient frequency (aka RPe) value through the the mailbox
command (0x1A) from the pcode, as done on Haswell and Broadwell.
The turbo minimum frequency softlimit is not revised as per the
efficient frequency value.
v2: Replaced the conditional expression operator with 'if' statement (Tom)
v3: Corrected the derivation of efficient frequency & shifted the
GEN9_FREQ_SCALER multiplications downwards (Ville)
Issue: VIZ-5143
Signed-off-by: Akash Goel <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This fbdev restore mode was another corner case that was now
calling frontbuffer flip and flush and making we miss
screen updates with PSR enabled.
So let's also add the invalidate hack here while we don't have
a reliable dirty fbdev op.
v2: As pointed by Paulo: removed seg fault risk, used fb_helper
when possible and put brackets on if.
Cc: Paulo Zanoni <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Testcase: igt/kms_fbcon_fbt/psr
Signed-off-by: Daniel Vetter <[email protected]>
|
|
fbdev_set_par is called when fbcon is taking over control.
In the past frontbuffer was being invalidated on
set_to_gtt_domain, but it moved to set_domain fixing that case,
but left this behind and broken in
commit 031b698a77a70a6c394568034437b5486a44e868
Author: Daniel Vetter <[email protected]>
Date: Fri Jun 26 19:35:16 2015 +0200
drm/i915: Unconditionally do fb tracking invalidate in set_domain
Note that even before this commit it wasn't perfect since the
invalidate was omitted if the fbcon was already in the GTT domain,
which it usually was.
Since we are also invalidating in other fbdev cases this one
was masked here. At least until now that I found this corner
case: On boot with plymouth doing a splash screen
when returning to the console frontbuffer wans't being invalidated
causing missed screen updates with PSR enabled.
So this patch fixes this issue.
v2: Make invalidate directly and unconditionally and
fix commit message indicating the set_domain fix
as pointed out by Daniel.
v3: Remove unecessary if(obj) added by mistake
Cc: Paulo Zanoni <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
[danvet: Try to clarify commit message a bit and make it clear the
referenced commit made this worse.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Idle frames the number of identical frames needed
before panel can enter PSR.
There are some panels that requires up to minimum of 4 idle
frames available on the market. For these cases usually
VBT should be used to configure the number of idle frames,
but unfortunately this isn't always true and VBT isn't being
set at all.
Let's trust VBT when it is set + 1 and use minimum of 4 + 1
when VBT isn't set. "+1" covers the "of-by-one" case.
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
By Spec we should only mask memup and hotplug detection
for hardware tracking cases. However we always masked
LPSP because with power well always enabled on audio
PSR was never being activated and residency was always
zeroed.
Apparently audio driver is tying power well management
and runtime PM for some reason. But with audio runtime
PM working or with audio completely out of picture
we should remove this mask, otherwise we have a high
risk of miss screen updates as faced by Matthew.
WARNING: With this patch if snd_intel_hda driver is
running and not releasing power well properly PSR will
constant Exit and Performance Counter will be 0.
But the best thing of this patch is that with one more
HW tracking working the risks of missed blank screen
are minimized at most.
This affects just core platforms where PSR exit are also
helped by HW tracking: Haswell, Broadwell and Skylake
for now.
v2: Fix commit message explanation. It has nothing to do
with runtime PM on i915 as previously advertised.
Cc: Daniel Vetter <[email protected]>
Cc: Matthew Garrett <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Reported by the kbuild test robot.
Regression introduced by:
commit fdbff9282c0f5f61ffc87d57461b04d943250910
Author: Daniel Vetter <[email protected]>
Date: Thu Jun 18 11:23:24 2015 +0200
drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
So make it static.
Signed-off-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Reported by the kbuild test robot.
Regression introduced by:
commit de152b627eb3018de91ec5c5a50b38e17d80a88b
Author: Rodrigo Vivi <[email protected]>
Date: Tue Jul 7 16:28:51 2015 -0700
drm/i915: Add origin to frontbuffer tracking flush
(I reviewed this commit, so it's also my fault)
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Let's do a frontbuffer flush on dirty fb.
To be used for DIRTYFB drm ioctl.
This patch solves the biggest PSR known issue, that is
missed screen updates during boot, mainly when there is a splash
screen involved like Plymouth.
Previously PSR was being invalidated by fbdev and Plymounth
was taking control with PSR yet invalidated and could get screen
updates normally. However with some atomic modeset changes
Pymouth modeset over ioctl was now causing frontbuffer flushes
making PSR gets back to work while it cannot track the
screen updates and exit properly.
By adding this flush on dirtyfb we properly track frontbuffer
writes and properly exit PSR.
Actually all mmap_wc users should call this dirty callback
in order to have a proper frontbuffer tracking.
In the future it can be extended to return 0 if the whole
screen has being flushed or the number of rects flushed
as Chris suggested.
v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
callback is just called after few screen updates and not on
everyone as pointed by Daniel.
v3: Use flush instead of invalidate since flush means
invalidate + flush and dirty means drawn had finished and
it can be flushed.
v4: Remove PSR from subject since it is purely frontbuffer tracking
change and that can be useful for FBC as well.
Cc: Chris Wilson <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
[danvet: Fix alignment as spotted by Paulo.]
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Since flush actually means invalidate + flush we need to force psr
exit on PSR flush.
On Core platforms there is no way to disable hw tracking and
do the pure sw tracking so we simulate it by fully disable psr and
reschedule a enable back.
So a good idea is to minimize sequential disable/enable in cases we
know that HW tracking like when flush has been originated by a flip.
Also flip had just invalidated it already.
It also uses origin to minimize the a bit the amount of
disable/enabled, mainly when flip already had invalidated.
With this patch in place it is possible to do a flush on dirty areas
properly in a following patch.
v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.
Cc: Paulo Zanoni <[email protected]>
Cc: Daniel Vetter <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This will be useful to PSR and FBC once we start making
dirty fb calls to also flush frontbuffer.
Cc: Daniel Vetter <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Paulo Zanoni <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
wa_ctx_emit() depends on the name of a local variable; if the name of that
variable is changed then we get compile errors. In this case it is unlikely
to be changed as this macro is only used in this set of functions but
Kernel coding guidelines doesn't recommend doing this. It was my mistake
as I should have corrected it at the beginning but missed so correct
this before there are more usages of this macro (Bob Beckett).
https://www.kernel.org/doc/Documentation/CodingStyle,
Chapter 12, "Things to avoid when using macros", point 2):
"
2) macros that depend on having a local variable with a magic name:
#define FOO(val) bar(index, val)
might look like a good thing, but it's confusing as hell when one reads the
code and it's prone to breakage from seemingly innocent changes.
"
v2: Optimization to avoid multiple evaluation of 'index' in the macro.
Since we invoke it multiple times, compiler, if it can, should be able to coalesce
them into a single condition and remove multiple WARN_ON checks (Chris).
Suggested-by: Robert Beckett <[email protected]>
Cc: Robert Beckett <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Imre Deak <[email protected]>
Signed-off-by: Arun Siluvery <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Writing to PCH_PORT_HOTPLUG for each interrupt is not required.
Handle it only if hpd has actually occurred like we handle other
interrupts.
v2: Make few variables local to if block (Ville)
v3: Add check for ibx/cpt both (Ville).
While at it, remove the redundant check for hotplug_trigger from
pch_get_hpd_pins
v4: Indentation (Ville)
Reviewed-by: Ville Syrjälä <[email protected]>
Signed-off-by: Sonika Jindal <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
So now all the calls are inside __intel_fbc_update(). Consistency!
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
I have two separate refactor ideas that require extracting this to a
separate function. I'm not sure which idea I'll end choosing, but
since both will require extracting this function, let's do this now.
Notice that this is just code moving. Any possible problems with the
current multiple pipes check should be fixed in later commits.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
The poor in_dbg_master() check was the only one without a reason
string. Give it a reason string so it won't feel excluded.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
This is all internal i915.ko work, let's start using intel_crtc for
everything.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Because the cool kids use dev_priv and FBC wants to be cool too.
We've been historically using struct drm_device on the FBC function
arguments, but we only really need it for intel_vgpu_active(): we can
use dev_priv everywhere else. So let's fully switch to dev_priv since
I'm getting tired of adding "struct drm_device *dev = dev_priv->dev"
everywhere.
If I get a NACK here I'll propose the opposite: convert all the
functions that currently take dev_priv to take dev.
Signed-off-by: Paulo Zanoni <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
|