Extend init/init_hw split to context init.
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality &
alloc/init split.
This patch is intended to split out the allocation of resources &
initialisation to allow easier reuse of code for resume/gpu reset.
v2: Removed function ptr wrapping of do_switch_context (Daniel Vetter)
Left ->init_context int intel_lr_context_deferred_alloc
(Daniel Vetter)
Remove unnecessary init flag & ring type test. (Daniel Vetter)
Improve commit message (Daniel Vetter)
v3: On init/reinit, set the hw next sequence number to the sw next
sequence number. This is set to 1 at driver load time. This prevents
the seqno being reset on reinit (Chris Wilson)
v4: Set seqno back to ~0 - 0x1000 at start-of-day, and increment by 0x100
on reset.
This makes it obvious which bbs are which after a reset. (David Gordon
& John Harrison)
Rebase.
v5: Rebase. Fixed rebase breakage. Put context pinning in separate
function. Removed code churn. (Thomas Daniel)
v6: Cleanup up issues introduced in v2 & v5 (Thomas Daniel)
Issue: VIZ-4798
Signed-off-by: Nick Hoath <nicholas.hoath@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: David Gordon <david.s.gordon@intel.com>
Cc: Thomas Daniel <thomas.daniel@intel.com>
Reviewed-by: Thomas Daniel <thomas.daniel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is done as a separate commit, to make it easier to revert
when things break.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Normally we determine the backlight PWM modulation frequency (which we
also use as backlight max value) from the backlight registers at module
load time, expecting the registers have been initialized by the BIOS. If
this is not the case, we fail.
The VBT contains the backlight modulation frequency in Hz. Add platform
specific functions to convert the frequency in Hz to backlight PWM
modulation frequency, and use them to initialize the backlight when the
registers are not initialized by the BIOS.
v2: Fix SPT and VLV. Thanks to Clint for the VLV code.
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make LPT:LP checks look neater by wrapping the details in a
new HAS_PCH_LPT_LP() macro.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge -fixes since there's more DDI-E related cleanups on top of
the pile of -fixes for skl that just landed for 4.3.
Conflicts:
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i914/intel_dp.c
drivers/gpu/drm/i915/intel_lrc.c
Conflicts are all fairly harmless adjacent line stuff.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Add a common function to return "yes" or "no" string based on the
argument, and drop the local versions of it.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The driver doesn't support UMS any more, so set DRIVER_MODESET by default,
remove the legacy s/r callbacks, and rename the s/r functions to make it more clear
they're only in use by switcheroo now.
Also remove an obsolete comment about atomic. Normal updates are supported only
async updates aren't yet.
v2: Don't unconditionally set DRIVER_ATOMIC, we're not yet there.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From B spec, DDI_E port belong to PowerWell 2, but
DDI_E share the powerwell_req/staus register bit with
DDI_A which belong to DDI_A_E_POWER_WELL.
In order to communicate with the connector on DDI-E, both
DDI_A_E_POWER_WELL and POWER_WELL_2 must be enabled.
Currently intel_dp_power_get(DDI_E) only enable
DDI_A_E_POWER_WELL, this patch will not only enable
DDI_a_E_POWER_WELL but also enable POWER_WELL_2.
This patch also fix the DDI-E hotplug function.
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
DDI-E doesn't have the correspondent GMBUS pin.
We rely on VBT to tell us which one it being used instead.
The DVI/HDMI on shared port couldn't exist.
This patch isn't tested without hardware wchich has HDMI
on DDI-E.
v2: fix trailing whitespace
v3: MISSING_CASE take place of BUG()
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This partially reverts commit 74c090b1bd.
The DRIVER_ATOMIC cap cannot yet be exported because i915 lacks async
support.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Store max dotclock into dev_priv structure so we are able
to filter out the modes that are not supported by our
platforms.
V2:
- limit the max dot clock frequency to max CD clock frequency
for the gen9 and above
- limit the max dot clock frequency to 90% of the max CD clock
frequency for the older gens
- for Cherryview the max dot clock frequency is limited to 95%
of the max CD clock frequency
- for gen2 and gen3 the max dot clock limit is set to 90% of the
2X max CD clock frequency
V3:
- max_dotclk variable renamed as max_dotclk_freq in i915_drv.h
- in intel_compute_max_dotclk() the rounding method changed from
round up to round down when computing max dotclock
V4:
- Haswell and Broadwell supports now dot clocks up to max CD clock
frequency
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The current versions of these two macros don't work correctly if the
argument expression happens to contain a modulo operator (%) -- when
stringified, it gets interpreted as a printf formatting character!
With a specifically crafted parameter, this could probably cause a
kernel OOPS; consider WARN_ON(p%s) or WARN_ON(f %*pEp).
Instead, we should use an explicit "%s" format, with the stringified
expression as the coresponding literal-string argument.
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: fix one error found by checkpath.pl
v3: Add one ignored break for switch-case. DDI-E hotplug
function doesn't work after updating drm-intel tree,
I checked the code and found this missing which isn't
the root cause for broke DDI-E hp. The broken
DDI-E hp function is fixed by "Adding DDI_E power
well domain".
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Tested-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Bunch more fixes for 4.3, most of it skl fallout. It's not quite all yet,
there's still a few more patches pending to enable DDI-E correctly on skl.
Also included the dpms atomic work from Maarten since atomic is just a
pain and not including would cause piles of conflicts right from the
start.
* tag 'drm-intel-next-fixes-2015-08-16' of git://anongit.freedesktop.org/drm-intel: (67 commits)
drm/i915: Per-DDI I_boost override
drm/i915/skl: WaIgnoreDDIAStrap is forever, always init DDI A
drm/i915: fix checksum write for automated test reply
drm/i915: Contain the WA_REG macro
drm/i915: Remove the failed context from the fpriv->context_idr
drm/i915: Report IOMMU enabled status for GPU hangs
drm/i915: Check idle to active before processing CSQ
drm/i915: Set alternate aux for DDI-E
drm/i915: Set power domain for DDI-E
drm/i915: fix stolen bios_reserved checks
drm/i915: Use masked write for Context Status Buffer Pointer
drm/i915/skl WaDisableSbeCacheDispatchPortSharing
drm/i915: Spam less on dp aux send/receive problems
drm/i915: Handle return value in intel_pin_and_fence_fb_obj, v2.
drm/i915: Only update mode related state if a modeset happened.
drm/i915: Remove connectors_active.
drm/i915: Remove connectors_active from intel_dp.c, v2.
drm/i915: Remove connectors_active from sanitization, v2.
drm/i915: Get rid of dpms handling.
drm/i915: Make crtc checking use the atomic state, v2.
...
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wilson
v3:
Removed 'wait' parameter to intel_guc_ucode_load() as firmware
prefetch is no longer supported in the common firmware loader,
per Daniel Vetter's request.
Firmware checker callback fn now returns errno rather than bool.
v4:
Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
Don't keep the driver working (by falling back to execlist mode)
if GuC firmware loading fails [Daniel Vetter]
v5:
Clarify WOPCM-related #defines [Tom O'Rourke]
Delete obsolete code no longer required with current h/w & f/w
[Tom O'Rourke]
Move the call to intel_guc_ucode_init() later, so that it can
allocate GEM objects, and have it fetch the firmware; then
intel_guc_ucode_load() doesn't need to fetch it later.
[Daniel Vetter].
v6:
Update comment describing intel_guc_ucode_load() [Tom O'Rourke]
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Similar to commit c44ef60e43 ("drm/i915/gtt:
Allow >= 4GB sizes for vm"), i915_gem_obj_offset and i915_gem_obj_ggtt_offset
return an unsigned long, which in only 4-bytes long in 32-bit kernels.
Change return type (and other related offset variables) to u64.
Since Global GTT is always limited to 4GB, this change would not be required
in i915_gem_obj_ggtt_offset, but this is done for consistency.
v2: Remove unnecessary offset variable in do_pin, as we already have
vma->node.start (Chris).
Update GGTT offset too (Tvrtko).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise it can overflow in 48-bit mode, and cause an incorrect
exec_start.
Before commit 5f19e2bffa ("drm/i915: Merged
the many do_execbuf() parameters into a structure"), it was already an u64.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
v2: For semaphore errors, object is mapped to GGTT and offset will not
be > 4GB, print only lower 32-bits (Akash)
v3: Print gtt_offset in groups of 32-bit (Chris)
Cc: Akash Goel <akash.goel@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduces the Page Map Level 4 (PML4), ie. the new top level structure
of the page tables.
To facilitate testing, 48b mode will be available on Broadwell and
GEN9+, when i915.enable_ppgtt = 3.
v2: Remove unnecessary CONFIG_X86_64 checks, ppgtt code is already
32/64-bit safe (Chris).
v3: Add goto free_scratch in temp 48-bit mode init code (Akash).
v4: kfree the pdp until the 4lvl alloc/free patch (Akash).
v5: Postpone 48-bit code in sanitize_enable_ppgtt (Akash).
v6: Keep _insert_pte_entries changes outside this patch (Akash).
Cc: Akash Goel <akash.goel@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
An OEM may request increased I_boost beyond the recommended values
by specifying an I_boost value to be applied to all swing entries for
a port. These override values are specified in VBT.
v2: rebase and remove unused iboost_bit variable
Issue: VIZ-5676
Signed-off-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge drm-intel-fixes because a bunch of atomic patch backporting
we had to do lead to horrible conflicts.
Conflicts:
drivers/gpu/drm/drm_crtc.c
Just a bit of context conflict between -next and -fixes.
drivers/gpu/drm/i915/intel_atomic.c
drivers/gpu/drm/i915/intel_display.c
Atomic conflicts, always pick the code from -next.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
The IOMMU for Intel graphics has historically had many issues resulting
in random GPU hangs. Lets include its status when capturing the GPU hang
error state for post-mortem analysis.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There is no correspondent Aux channel for DDI-E.
So we need to rely on VBT to let us know witch one
is being used instead.
v2: Removing some trailing spaces and giving proper
credit to Xiong that added a nice way to avoid port
conflicts by setting supports_dp = 0 when using
equivalent aux for DDI-E.
Credits-to: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Xiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of our own duplicated one. This fixes a bug in the driver
unload code if DRM_FBDEV_EMULATION=n but DRM_I915_FBDEV=y because we
try to unregister the nonexistent fbdev drm_framebuffer.
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch contains the changes to remove the byte
swapping logic introduced with old dmc firmware.
While debugging PC10 entry issue for skylake found
with latest dmc firmware version 1.18 without byte
swapping dmc is working fine and able to enter PC10.
Note that apparently this was changed with dmc version 1.0 and earlier
ones indeed are byteswapped like this ...
v1: Initial version.
v2: Corrected firmware size during memcpy(). (Suggested by Sunil)
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Sunil Kamath <sunil.kamath@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Vathsala Nagaraju <vathsala.nagaraju@intel.com>
Reviewed-by: A.Sunil Kamath <sunil.kamath@intel.com>
[danvet: Add note that this only holds for released dmc firmware.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
First, an introduction. We currently have two types of GTT mmaps: the
"normal" old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated as
ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
tracking are destined to fail.
One of the special rules defined for the WC mmaps is that the user
should call the dirtyfb IOCTL after he is done using the pointers, so
that results in an intel_fb_obj_flush() call. The problem is that the
dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
though the hardware tracking is not detecing the WC mmap operations.
So in order to fix that without having to give up the automatic
hardware tracking for GTT mmaps we transform the flush operation from
dirtyfb into a special operation: ORIGIN_DIRTYFB.
This commit fixes all the kms_frontbuffer_tracking subtests that
contain "fbc" and "mmap-wc" in their names and are currently failing
(for a total of 16 subtests).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since we may conceivably encounter situations where the upper part of the
64bit register changes between reads, for example when a timestamp
counter overflows, change the WARN into a retry loop.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Remove the leftovers, yay!
AGP for i915 kms died long ago with
commit 3bb6ce6686
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Nov 13 22:14:16 2013 +0100
drm/i915: Kill legeacy AGP for gen3 kms
and with ums now gone to there's really no users any more.
Note that device_is_agp is only called when DRIVER_USE_AGP is set and
since we've unconditionally cleared that since a while there are
really no users left for i915_driver_device_is_agp.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
It fits more with the low-level fence code, and this move leaves only
the userspace tiling ioctl handling in i915_gem_tiling.c.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
No code changes, just moving all the fence related code into a
separate file (and avoiding a bunch of forward declarations while at
it).
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Currently HPD_PORT_A is used as an alias for HPD_NONE to mean that the
given port doesn't support long/short HPD pulse detection. SDVO and CRT
ports are like this and for these ports we only want to know whether an
hot plug event was detected on the corresponding pin. Since at least on
BXT we need long/short pulse detection on PORT A as well (added by the
next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the
return value of intel_hpd_pin_to_port() show whether long/short pulse
detection is supported on the passed in pin.
No functional change.
v2:
- rebase on top of -nightly (Daniel)
- make the check for intel_hpd_pin_to_port() return value more readable
(Sivakumar)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Two new module parameters: "enable_guc_submission" which will turn
on submission of batchbuffers via the GuC (when implemented), and
"guc_log_level" which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai <yu.dai@intel.com>
v4:
Mark "enable_guc_submission" unsafe [Daniel Vetter]
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(), originally by Alex Dai
v2:
Change of function: now allocates & fills a new object, rather than
writing to an existing object
New name courtesy of Chris Wilson
Explicit domain-setting and other improvements per review comments
by Chris Wilson & Daniel Vetter
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai <yu.dai@intel.com>
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Tom O'Rourke <Tom.O'Rourke@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Backmerge fixes since it's getting out of hand again with the massive
split due to atomic between -next and 4.2-rc. All the bugfixes in
4.2-rc are addressed already (by converting more towards atomic
instead of minimal duct-tape) so just always pick the version in next
for the conflicts in modeset code.
All the other conflicts are just adjacent lines changed.
Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_drv.h
drivers/gpu/drm/i915/intel_ringbuffer.h
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Huzzah! \o/
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <daniel.vetter@ffwll.ch>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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 <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
After the previous patch this flag will check always clear, as it's
never set for shmem backed and userptr objects, so we can remove it.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Yeah this isn't really fixes but it's a nice cleanup to
clarify the code but not really worth the hassle of backmerging. So
just add to -fixes, we're still early in -rc.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This broken code was introduced in
commit aa7471d228
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 1 11:15:21 2015 +0300
drm/i915: add i915 specific connector debugfs file for DPCD
v2: Drop hunk that accidentally crept in.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: François Valenduc <francoisvalenduc@gmail.com>
Reported-by: François Valenduc <francoisvalenduc@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
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 <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is all internal i915.ko work, let's start using intel_crtc for
everything.
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>
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 <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because it makes more sense there, IMHO.
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>
