__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep. Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep. The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake. As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags. This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.
[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
__GFP_WAIT has been used to identify atomic context in callers that hold
spinlocks or are in interrupts. They are expected to be high priority and
have access one of two watermarks lower than "min" which can be referred
to as the "atomic reserve". __GFP_HIGH users get access to the first
lower watermark and can be called the "high priority reserve".
Over time, callers had a requirement to not block when fallback options
were available. Some have abused __GFP_WAIT leading to a situation where
an optimisitic allocation with a fallback option can access atomic
reserves.
This patch uses __GFP_ATOMIC to identify callers that are truely atomic,
cannot sleep and have no alternative. High priority users continue to use
__GFP_HIGH. __GFP_DIRECT_RECLAIM identifies callers that can sleep and
are willing to enter direct reclaim. __GFP_KSWAPD_RECLAIM to identify
callers that want to wake kswapd for background reclaim. __GFP_WAIT is
redefined as a caller that is willing to enter direct reclaim and wake
kswapd for background reclaim.
This patch then converts a number of sites
o __GFP_ATOMIC is used by callers that are high priority and have memory
pools for those requests. GFP_ATOMIC uses this flag.
o Callers that have a limited mempool to guarantee forward progress clear
__GFP_DIRECT_RECLAIM but keep __GFP_KSWAPD_RECLAIM. bio allocations fall
into this category where kswapd will still be woken but atomic reserves
are not used as there is a one-entry mempool to guarantee progress.
o Callers that are checking if they are non-blocking should use the
helper gfpflags_allow_blocking() where possible. This is because
checking for __GFP_WAIT as was done historically now can trigger false
positives. Some exceptions like dm-crypt.c exist where the code intent
is clearer if __GFP_DIRECT_RECLAIM is used instead of the helper due to
flag manipulations.
o Callers that built their own GFP flags instead of starting with GFP_KERNEL
and friends now also need to specify __GFP_KSWAPD_RECLAIM.
The first key hazard to watch out for is callers that removed __GFP_WAIT
and was depending on access to atomic reserves for inconspicuous reasons.
In some cases it may be appropriate for them to use __GFP_HIGH.
The second key hazard is callers that assembled their own combination of
GFP flags instead of starting with something like GFP_KERNEL. They may
now wish to specify __GFP_KSWAPD_RECLAIM. It's almost certainly harmless
if it's missed in most cases as other activity will wake kswapd.
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Vitaly Wool <vitalywool@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Arguments passed to list_add_tail were reversed resulting in deletion
of old blob property everytime the new one is added.
Fixes
commit e2f5d2ea47
Author: Daniel Stone <daniels@collabora.com>
Date: Fri May 22 13:34:51 2015 +0100
drm/mode: Add user blob-creation ioctl
Signed-off-by: Maneet Singh <mmaneetsingh@nvidia.com>
[seanpaul tweaked commit subject a little]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Cc: stable@kernel.org # v4.2
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
The size here comes from the user via the ioctl, it is a number between
1-u32max so the addition here could overflow on 32 bit systems.
Fixes: f453ba0460 ('DRM: add mode setting support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: stable@kernel.org # v4.2
Signed-off-by: Dave Airlie <airlied@gmail.com>
If driver backlight control is disabled, either by driver
parameter or default per-asic setting, revert to the old behavior.
Fixes a regression in commit:
4281f46ef8
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
So that the bl encoder will be null if the GPU does not
control the backlight.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
An spi_driver does not need to set an owner, it will be populated by the
driver core.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
I'm not sure whether this patch comes in too late, but it would be good to
have it in. It stabilizes command submission in case of command buffer errors.
* 'vmwgfx-fixes-4.3' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Stabilize the command buffer submission code
Just a crash fix for radeon and amdgpu if the user has forcibly disabled
dpm and tries to access the pwm sysfs controls.
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: add missing dpm check for KV dpm late init
drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
drm/radeon/dpm: don't add pwm attributes if DPM is disabled
The revert dance could use some explanation: we had stuff fixed in
-next, and initially backported one commit to v4.3. Now, turns out we
need more fixes, and we could cherry-pick them all without conflicts if
we reverted the backported one first. So did that to not have to edit
and backport them all.
* tag 'drm-intel-fixes-2015-10-16' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Add primary plane to mask if it's visible
drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()
drm/i915: Assign hwmode after encoder state readout
Revert "drm/i915: Add primary plane to mask if it's visible"
drm/i915: Deny wrapping an userptr into a framebuffer
drm/i915: Enable DPLL VGA mode before P1/P2 divider write
drm/i915: Restore lost DPLL register write on gen2-4
drm/i915: Flush pipecontrol post-sync writes
drm/i915: Fix kerneldoc for i915_gem_shrink_all
Just one fix from Ilia to resolve various issues that have resulted from
buffer eviction.
* 'linux-4.3' of git://anongit.freedesktop.org/nouveau/linux-2.6:
drm/nouveau/gem: return only valid domain when there's only one
On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.
This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In Linux 4.3-rc5, there is an error case in drm_dp_get_branch_device
that returns without releasing mgr->lock, resulting a spew of kernel
messages about a kernel work function possibly having leaked a mutex
and presumably more serious adverse consequences later. This patch
changes the error to "goto out" to unlock the mutex before returning.
[airlied: grabbed from drm-next as it fixes something we've seen]
Signed-off-by: Adam J. Richter <adam_richter2004@yahoo.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit addresses some stability problems with the command buffer
submission code recently introduced:
1) Make the vmw_cmdbuf_man_process() function handle reruns internally to
avoid losing interrupts if the caller forgets to rerun on -EAGAIN.
2) Handle default command buffer allocations using inline command buffers.
This avoids rare allocation deadlocks.
3) In case of command buffer errors we might lose fence submissions.
Therefore send a new fence after each command buffer error. This will help
avoid lengthy fence waits.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
PWM fan control is only available with DPM. There is no non-DPM
support on amdgpu, so we should never get a crash here because
the sysfs nodes would never be created in the first place. Add the
check just in case to be on the safe side.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:
drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'long long int' [-Wformat=]
snprintf(str, size, "%lu", atomic64_read(&fence->drv->last_seq));
^
drivers/gpu/drm/virtio/virtgpu_debugfs.c: In function 'virtio_gpu_debugfs_irq_info':
drivers/gpu/drm/virtio/virtgpu_debugfs.c:37:16: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int' [-Wformat=]
seq_printf(m, "fence %ld %lld\n",
^
In order to avoid the warnings, this changes the format strings to %llu
and adds a cast to u64, which makes it work the same way everywhere.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull request of 2015-10-14
* tag 'vmwgfx-fixes-4.3-151014' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix kernel NULL pointer dereference on older hardware
This fixes flickering issues caused by prematurely firing pflip
interrupts.
v2 (chk): add commit message, fix DCE V10/V11 and DM as well
v3: Re-enable pflip interrupt wherever we re-enable a CRTC
v4: Enable pflip interrupt in DAL as well
v5: drop DAL changes for upstream
v6: (agd): only enable interrupts on crtcs that exist
v7: (agd): integrate suggestions from Michel
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Set the default to 600Mhz if it's not set in the bios,
and bump the default to 600Mhz if it's lower than that.
Port of radeon commit:
9368931db8
v2: clean up the code a bit
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=91896
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This zeroes the msg so no random stack data ends up getting
sent, it also limits the function to not accepting > 4
i2c msgs.
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes the warnings like
"plane A assertion failure, should be disabled but not"
that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.
Most likely caused by
commit 36750f284b
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Mon Jun 1 12:49:54 2015 +0200
drm/i915: update plane state during init
This is a new version of
commit 721a09f739
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date: Tue Sep 15 14:28:54 2015 +0200
drm/i915: Add primary plane to mask if it's visible
That was reverted in order to facilitate easier backporting of some
commits from -next to v4.3.
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429
Reported-and-tested-by: Emil Renner Berthing <kernel@esmil.dk>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().
The plane disabling was first added in
4cf0ebbd4f drm/i915: Rework plane readout.
I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.
Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled
v2: Steal Maarten's idea to move crtc->mode etc. assignment too
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts commit 721a09f739.
There is nothing wrong with the commit per se. We had two versions of
the commit, one in -next headed for v4.4 and this one for v4.3. Turns
out we'll need to backport more fixes from -next, and they conflict with
the v4.3 version. It gets messy. It will be easiest to revert this one,
and backport all the relevant commits from -next without modifications;
they apply cleanly after this revert.
Requested-by: Joseph Yasi <joe.yasi@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910#c4
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apparently writing the DPLL register P1/P2 divider fields won't trigger
an actual change in the DPLL output unless VGA mode is enabled for
prior to the register write that changes the P1/P2 dividers. The write
with the new P1/P2 divider can itself disable VGA mode again without
problems.
I tested the behaviour on my 946GZ, and when manually frobbing the
register with the display on, the behaviour is very clear. However I
can't explain why this machine actually works. The P1/P2 divider
changes caused by normal modesets do seem to make it through to the
hardware somehow since I get a stable picture on the monitor with
any resolution. Maybe it's the "three times for luck" stuff that
somehow masks the problem, or something.
But apparently there are machines (eg. Nick Bowler's G45) where that
isn't the case and we fail to get the correct clock from the DPLL.
Things used to work because we enabled VGA mode for disabled DPLLs,
so when re-enabling the DPLL VGA mode was enabled just prior to the
first register write, and hence the P1/P2 change went through without
a hitch. That got changed in
b8afb9113c drm/i915: Keep GMCH DPLL VGA mode always disabled
in the name of consistency. In order to keep the consistency part,
leave VGA mode disabled for disabled DPLLs, but turn it on just prior
to updating the P1/P2 dividers to make sure the hardware picks up
on the new values.
Cc: Nick Bowler <nbowler@draconx.ca>
Reported-by: Nick Bowler <nbowler@draconx.ca>
Tested-by: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We accidentally lost the initial DPLL register write in
1c4e027461 drm/i915: Fix DVO 2x clock enable on 830M
The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.
Reported-and-tested-by: Nick Bowler <nbowler@draconx.ca>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: stable@vger.kernel.org
Cc: Nick Bowler <nbowler@draconx.ca>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In order to flush the results from in-batch pipecontrol writes (used for
example in glQuery) before declaring the batch complete (and so declaring
the query results coherent), we need to set the FlushEnable bit in our
flushing pipecontrol. The FlushEnable bit "waits until all previous
writes of immediate data from post-sync circles are complete before
executing the next command".
I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I've botched this in
commit eb0b44adc0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 18 14:47:59 2015 +0100
drm/i915: kerneldoc for i915_gem_shrinker.c
so let's fix it.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The commit "drm/vmwgfx: Fix up user_dmabuf refcounting", while fixing a
kernel crash introduced a NULL pointer dereference on older hardware.
Fix this.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Nothing too crazy here, a couple of regression fixes + runpm/fbcon
race fix.
* 'linux-4.3' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/bios: fix OF loading
drm/nouveau/fbcon: take runpm reference when userspace has an open fd
drm/nouveau/nouveau: Disable AGP for SiS 761
drm/nouveau/display: allow up to 16k width/height for fermi+
drm/nouveau/bios: translate devinit pri/sec i2c bus to internal identifiers
Currently OF bios load fails for a few reasons:
- checksum failure
- bios size too small
- no PCIR header
- bios length not a multiple of 4
In this change, we resolve all of the above by ignoring any checksum
failures (since OF VBIOS tends not to have a checksum), and faking the
PCIR data when loading from OF.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to do this in order to prevent accesses to the device while it's
powered down. Userspace may have an mmap of the fb, and there's no good
way (that I know of) to prevent it from touching the device otherwise.
This fixes some nasty races between runpm and plymouth on some systems,
which result in the GPU getting very upset and hanging the boot.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
SiS 761 chipset does not support AGP cards but has AGP capability (for
the onboard video). At least PC Chips A31G board using this chipset has
an AGP-like AGPro slot that's wired to the PCI bus. Enabling AGP will
fail (GPU lockup and software fbcon, X11 hangs).
Add support for matching just the host bridge in nvkm_device_agp_quirks
and add entry for SiS 761 with mode 0 (AGP disabled).
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
With atomic drivers we need to make sure that (at least in general)
property reads hold the right locks. But the legacy dpms property is
special and can be read locklessly. Since userspace loves to just
randomly look at that all the time (like with "status") do that.
To make it clear that we play tricks use the READ_ONCE compiler
barrier (and also for paranoia).
Note that there's not really anything bad going on since even with the
new atomic paths we eventually end up not chasing any pointers (and
hence possibly freed memory and other fun stuff). The locking WARNING
has been added in
commit 88a48e297b
Author: Rob Clark <robdclark@gmail.com>
Date: Thu Dec 18 16:01:50 2014 -0500
drm: add atomic properties
but since drivers are converting not everyone will have seen this from
the start.
Jens reported this and submitted a patch to just grab the
mode_config.connection_mutex, but we can do a bit better.
v2: Remove unused variables I failed to git add for real.
Reference: http://mid.gmane.org/20150928194822.GA3930@kernel.dk
Reported-by: Jens Axboe <axboe@fb.com>
Tested-by: Jens Axboe <axboe@fb.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
radeon and amdgpu fixes for 4.3. Highlights:
- Move pm sysfs setup later in the driver init process to avoid
problems with laptop scripts attempting to change pm settings
before the driver has finished setting up the pm hardware.
- Fix console restore if a drm app (e.g. X) is forcibly killed
- Flag iceland support as experimental for now
- Misc bug fixes
* 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu: fix memory leak in amdgpu_vm_update_page_directory
drm/amdgpu: fix 32-bit compiler warning
drm/amdgpu: flag iceland as experimental
drm/amdgpu: check before checking pci bridge registers
drm/amdgpu: fix num_crtc on CZ
drm/amdgpu: restore the fbdev mode in lastclose
drm/radeon: restore the fbdev mode in lastclose
drm/radeon: add quirk for ASUS R7 370
drm/amdgpu: add pm sysfs files late
drm/radeon: add pm sysfs files late
The new amdgpu driver passes a user space pointer in a 64-bit structure
member, which is the correct way to do it, but it attempts to
directly cast it to a __user pointer in the kernel, which causes
a warning in three places:
drm/amd/amdgpu/amdgpu_cs.c: In function 'amdgpu_cs_parser_init':
drm/amd/amdgpu/amdgpu_cs.c:180:21: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
chunk_array_user = (uint64_t __user *)(cs->in.chunks);
This changes all three to add an intermediate cast to 'unsigned long'
as other drivers do. This avoids the warning and works correctly on
both 32-bit and 64-bit architectures.
Fixes: e60b344f6c ("drm/amdgpu: optimize amdgpu_parser_init")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
qxl_bo_unref calls drm_gem_object_unreference_unlocked which
locks dev->struct_mutex. However this lock could be already
locked if the call came from qxl_gem_object_free.
As we don't need to call qxl_bo_ref/qxl_bo_unref cause
qxl_release_list_add will hold a reference by itself avoid
to call them and the possible deadlock.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoid a dependency lock error.
According to https://lwn.net/Articles/548909/ users of WW mutex API
should avoid using different context.
When a buffer is reserved with qxl_bo_reserve a ww_mutex_lock without
context is used. However during qxl_draw_dirty_fb different locks
with specific context are used.
This is detected during a machine booting with a debug kernel with lock
dependency checking enabled.
Like many other function in this file to avoid this problem object
pinning is used. Once the object is pinned is not necessary to keep
the lock so it can be released avoiding the locking problem.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
