Preparation for some runtime pm fixes. Currently we skip over fbcon
suspend/resume in the runtime path, which causes issues on resume if
fbcon tries to write to the framebuffer before the BAR subdev has
been resumed to restore the BAR1 VM setup.
As we might be woken up via a sysfs connector, we are unable to call
fb_set_suspend() in the resume path as it could make its way down to
a modeset and cause all sorts of locking hilarity.
To solve this, we'll just delay the fbcon resume to a workqueue.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Xorg (and any non-DRM client really) doesn't have permission to directly
touch VRAM on nv50 and up, which the fence code prior to g84 depends on.
It's less invasive to temporarily grant it premission to do so, as it
previously did, than it is to rework fencenv50 to use the VM. That
will come later on.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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>
legacy_connector_convert is used in radeon_combios.c only, so declare it as static.
Signed-off-by: Michele Curti <michele.curti@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The tables:
* supported_devices_connector_convert
* supported_devices_connector_object_id_convert
* object_connector_convert
are used in redeon_atombios.c only, so declare them as static.
Signed-off-by: Michele Curti <michele.curti@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This should allow the audio driver to get a better
idea of whether the sink is connected or not.
v2: fix copy/paste typo noticed by David Henningsson
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Most of that functionality is only used by r600_hdmi.c
and I'm planning to change that further.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
fixups for nouveau and fencing
* 'for-airlied-next' of git://people.freedesktop.org/~mlankhorst/linux:
drm/nouveau: export reservation_object from dmabuf to ttm
drm/ttm: add reservation_object as argument to ttm_bo_init
drm: Pass dma-buf as argument to gem_prime_import_sg_table
drm/nouveau: assign fence_chan->name correctly
drm/nouveau: specify if interruptible wait is desired in nouveau_fence_sync
drm/nouveau: bump driver patchlevel to 1.2.1
Ok, here's the update core-stuff pull request with the locking fixup patch
fixed up with another patch.
* tag 'topic/core-stuff-2014-09-29' of git://anongit.freedesktop.org/drm-intel:
drm: Drop grab fpriv->fbs_lock in drm_fb_release
drm/udl: use container_of to resolve udl_fbdev from drm_fb_helper
drm/ast: use container_of to resolve ast_fbdev from drm_fb_helper
drm/gma500: use container_of to resolve psb_fbdev from drm_fb_helper
drm/qxl: use container_of to resolve qxl_fbdev from drm_fb_helper
drm/nouveau: use container_of to resolve nouveau_plane from drm_plane
drm/nouveau: use container_of to resolve nouveau_fbdev from drm_fb_helper
drm/radeon: use container_of to resolve radeon_fbdev from drm_fb_helper
drm/mgag200: use container_of to resolve mga_fbdev from drm_fb_helper
drm/cirrus: use container_of to resolve cirrus_fbdev from drm_fb_helper
drm: Improve debug output for drm_wait_one_vblank
drm: Fixup locking for universal cursor planes
drm: Don't update vblank timestamp when the counter didn't change
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>
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>
Make nouveau_fence_chan refcounted, to make trace_fence_destroy
always return the correct name without a race condition.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.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>
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>
This fixes a regression introduced by "drm/nouveau: rework to new fence interface"
(commit 29ba89b237).
The fence sequence should not be reset after creation, the old value is used instead.
On destruction the final value is written, to prevent another source of accidental
wraparound in case of a channel being destroyed after a hang, and unblocking any other
channel that may wait on the about-to-be-deleted channel to signal.
I'm nothing if not optimistic about any hope of recovery from that. ;-)
Reported-by: Ted Percival <ted@tedp.id.au>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Tested-by: Ted Percival <ted@tedp.id.au>
Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93ca (ACPI / i915: ignore firmware requests
for backlight change). Then there is a Dell laptop whose vendor backlight
interface also makes use of operation region to change backlight level
and with the above commit, that interface no long works. The condition
used to ignore the backlight change request from firmware is thus
changed to: if the vendor backlight interface is not in use and the ACPI
backlight interface is broken, we ignore the requests; oterwise, we keep
processing them.
Fixes: 0b9f7d93ca (ACPI / i915: ignore firmware requests for backlight change)
Link: https://lkml.org/lkml/2014/9/23/854
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Cc: 3.16+ <stable@vger.kernel.org> # 3.16+
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@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>
