| Age | Commit message (Collapse) | Author |
|---|
|
MSI_REARM_EN register is a write only trigger register.
There is no need RMW when re-arming.
May fix:
https://bugs.freedesktop.org/show_bug.cgi?id=41668
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
- Add missing DFP6 connection state handling
- crtc routing bits not used on DCE4+
Noticed by sylware on phoronix.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Silly bad return path.
Reported-and-Tested-by: Mikko Vinni
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux into drm-fixes
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux:
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT (v2)
drm/i915: no lvds quirk for AOpen MP45
drm/i915: Force explicit bpp selection for intel_dp_link_required
drm/i915: fixup interlaced bits clearing in PIPECONF on PCH_SPLIT
drm/i915:: Disable FBC on SandyBridge
|
|
An identical patch has been merged for i9xx_crtc_mode_set:
Commit 59df7b1771c150163e522f33c638096ab0efbf42
Author: Christian Schmidt <schmidt@digadd.de>
Date: Mon Dec 19 20:03:33 2011 +0100
drm/intel: Fix initialization if startup happens in interlaced mode [v2]
But that one neglected to fix up the ironlake+ path.
This should fix the issue reported by Alfonso Fiore where booting with
only a HDMI cable connected to his TV failed to display anything. The
issue is that the bios set up things for 1080i and used the pannel
fitter to scale up the lower progressive resolutions. We failed to
clear the interlace bit in the PIPEACONF register, resulting in havoc.
v2: Be more paranoid and just unconditionally clear the field before
setting new values.
Cc: Peter Ross <pross@xvid.org>
Cc: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
According to a bug report, it doesn't have one.
Cc: stable@kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.
intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.
* intel_dp_mode_valid is called to list supported modes; in this case,
the current crtc values cannot be relevant as the modes in question
may never be selected. Thus, using intel_crtc->bpp is never right.
* intel_dp_mode_fixup is called during mode setting, but it is run
well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
so using intel_crtc-bpp in this path can only ever get a stale
value.
Cc: Lubos Kolouch <lubos.kolouch@gmail.com>
Cc: Adam Jackson <ajax@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881
Tested-by: Dave Airlie <airlied@redhat.com>
Tested-by: camalot@picnicpark.org (Dell Latitude 6510)
Tested-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
This return statement got dropped while fixing the conflicts introduced
in 7a7e8734ac3.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The c32 structure is allocated on the stack and its idx field is not
initialized before copying it to user level. This patch takes the value
from the result of the ioctl, as done for the other fields.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Evergreen and NI blit copy was broken if the buffer maps to a rectangle
whose one dimension is 16384 (max dimension allowed by these chips).
In the mainline kernel, the problem is exposed only when buffers are
very large (1G), but it's still a problem. The problem could be exposed
for smaller buffers if anyone modifies the algorithm for rectangle
construction in r600_blit_create_rect() (the reason why someone would
modify that algorithm is to tune the performance of buffer moves).
The root cause was in i2f() function which only operated on range between
0 and 16383. Fix this by extending the range of i2f() function to 0 to
32767.
While at it improve the function so that the range can be easily
extended in the future (if it becomes necessary), cleanup lines
over 80 characters, and replace in-line comments with one strategic
comment that explains the crux of the function.
Credits to michel@daenzer.net for pointing out the root cause of
the bug.
v2: Fix I2F_MAX_INPUT constant definition goof and warn only once
if input argument is out of range. Edit the comment a little
bit to avoid some linguistic confusion and make it look better
in general.
Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel@daenzer.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Different versions of the DP to LVDS bridge chip
need different panel mode settings depending on
the chip version used.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=45503
Reported-and-Debugged-by: mlambda@gmail.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Properly set the parent device of DP i2c buses before registering them
too.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
The value of this register is transferred to the V_COUNTER register at the
beginning of vertical blank. V_COUNTER is the reference for VLINE waits and
goes from VIEWPORT_Y_START to VIEWPORT_Y_START+VIEWPORT_HEIGHT during scanout,
so if VIEWPORT_Y_START is not 0, V_COUNTER actually went backwards at the
beginning of vertical blank, and VLINE waits excluding the whole scanout area
could never finish (possibly only if VIEWPORT_Y_START is larger than the length
of vertical blank in scanlines). Setting DESKTOP_HEIGHT to the framebuffer
height should prevent this for any kind of VLINE wait.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=45329 .
CC: stable@vger.kernel.org
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Polling the outputs when the device is suspended can result in erroneous
status updates. Disable output polling during suspend to prevent this
from happening.
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
calc_mclk() returns zero on success and negative on failure but clk is
a u32.
v2: Martin Peres:
- clk should be an int, not a u32
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Due to a race it was possible for a fence to be destroyed while another
thread was trying to synchronise with it. If this happened in the fallback
non-semaphore path, it lead to the following oops due to fence->channel
being NULL.
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau]
*pde = a649c067
SMP
Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi]
Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM
EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1
EIP is at nouveau_fence_update+0xe/0xe0 [nouveau]
EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000
ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000)
Stack:
7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f
00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0
00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000
Call Trace:
[<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau]
[<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau]
[<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau]
[<fa964046>] validate_list+0x176/0x300 [nouveau]
[<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm]
[<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau]
[<c0406481>] ? die+0x31/0x80
[<f7c93d98>] drm_ioctl+0x388/0x490 [drm]
[<c0406481>] ? die+0x31/0x80
[<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau]
[<c0635c7b>] ? file_has_perm+0xcb/0xe0
[<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm]
[<c0564f56>] do_vfs_ioctl+0x86/0x5b0
[<c0406481>] ? die+0x31/0x80
[<c0635f22>] ? selinux_file_ioctl+0x62/0x130
[<c0554f30>] ? fget_light+0x30/0x340
[<c05654ef>] sys_ioctl+0x6f/0x80
[<c099e3a4>] syscall_call+0x7/0xb
[<c0406481>] ? die+0x31/0x80
[<c0406481>] ? die+0x31/0x80
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There's at least one known case where our shadowing code is buggy, and we
fail init. Until we can be confident we're doing all this correctly, lets
succeed and risk crazy bios tables rather than failing for perfectly valid
configs too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Reported-by: Yuriy Khomchik <homyur@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
The assignment of handle in vmw_framebuffer_create_handle doesn't actually do anything useful and is incorrectly assigning an integer value to a pointer argument. It appears that this is a typo and should be dereferencing handle rather than assigning to it directly. This fixes a bug where an undefined handle value is potentially returned to user-space.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Reviewed-by: Jakob Bornecrantz<jakob@vmware.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Dave Airlie <airlied@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
In particular, I found I was hitting the max-file limit in the VFS,
and the EFILE was being magically transformed into ENOMEM. Confusion
reigns.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
This reverts commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118.
Where is that paper bag ... ah here.
I've failed to take an odd interaction between my other cleanups and
this reclaim_buffers patch into account and also failed to properly
test it. Looks like there are more dragons and hidden trapdoors in the
drm release path than actual lines of code.
Until I get a clue, let's just revert this.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
An identical patch has been merged for i9xx_crtc_mode_set:
Commit 59df7b1771c150163e522f33c638096ab0efbf42
Author: Christian Schmidt <schmidt@digadd.de>
Date: Mon Dec 19 20:03:33 2011 +0100
drm/intel: Fix initialization if startup happens in interlaced mode [v2]
But that one neglected to fix up the ironlake+ path.
This should fix the issue reported by Alfonso Fiore where booting with
only a HDMI cable connected to his TV failed to display anything. The
issue is that the bios set up things for 1080i and used the pannel
fitter to scale up the lower progressive resolutions. We failed to
clear the interlace bit in the PIPEACONF register, resulting in havoc.
Cc: Peter Ross <pross@xvid.org>
Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Enabling FBC is causing the BLT ring to run between 10-100x slower than
normal and frequently lockup. The interim solution is disable FBC once
more until we know why.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Both the suspend and resume functions incorrectly set psbfb =
to_psb_fb(NULL) outside of the loop over all of the framebuffers. Fix
this by moving the assignment of psbfb inside the loop and removing the
initialisation of fb.
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
this patch separates fimd specific power on/off function from pm function
and the pm interfaces will call that function for power on or off.
and also removes unnecessary codes of resume function.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
FB based FIMD and DRM based FIMD drivers use same hardware
so with this patch, only one of them would be selected.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
DRM_EXYNOS_HDMI driver and VIDEO_SAMSUNG_S5P_TV driver should be
not enabled at once because they use same HW blocks. So dependency
for DRM_EXYNOS_HDMI is fixed to check VIDEO_SAMSUNG_S5P_TV=n.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
To make a api pair of request_mem_region and release_mem_region,
release_mem_region is used instead of release_resource.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
|
|
into drm-fixes
* 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux: (24 commits)
drm/i915: fixup forcewake spinlock fallout in drpc debugfs function
drm/i915: debugfs: show semaphore registers also on gen7
drm/i915: allow userspace forcewake references also on gen7
drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.
drm/i915: Correct debugfs printout for RC1e.
Revert "drm/i915: Work around gen7 BLT ring synchronization issues."
drm/i915: rip out the HWSTAM missed irq workaround
drm/i915: paper over missed irq issues with force wake voodoo
drm/i915: Hold gt_lock across forcewake register reads
drm/i915: Hold gt_lock during reset
drm/i915: Move reset forcewake processing to gen6_do_reset
drm/i915: protect force_wake_(get|put) with the gt_lock
drm/i915: convert force_wake_get to func pointer in the gpu reset code
drm/i915: sprite init failure on pre-SNB is not a failure
drm/i915: VBT Parser cleanup for eDP block
drm/i915: mask transcoder select bits before setting them on LVDS
drm/i915: Add Clientron E830 to the ignore LVDS list
CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB
drm/i915: handle 3rd pipe
drm/i915: simplify pipe checking
...
|
|
Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious
regressions in the nouveau driver.
move_notify() was originally able to presume that bo->mem is the old node,
and new_mem is the new node. The above commit moves the call to
move_notify() to after move() has been done, which means that now, sometimes,
new_mem isn't the new node at all, bo->mem is, and new_mem points at a
stale, possibly-just-been-killed-by-move node.
This is clearly not a good situation. This patch reverts this change, and
replaces it with a cleanup in the move() failure path instead.
The second issue is that the call to move_notify() from cleanup_memtype_use()
causes the TTM ghost objects to get passed into the driver. This is clearly
bad as the driver knows nothing about these "fake" TTM BOs, and ends up
accessing uninitialised memory.
I worked around this in nouveau's move_notify() hook by ensuring the BO
destructor was nouveau's. I don't particularly like this solution, and
would rather TTM never pass the driver these objects. However, I don't
clearly understand the reason why we're calling move_notify() here anyway
and am happy to work around the problem in nouveau instead of breaking the
behaviour expected by other drivers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Jerome Glisse <j.glisse@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
My forcewake spinlock patches have a functional conflict with Ben
Widawsky's gen6 drpc support for debugfs. Result was a benign warning
about trying to read an non-atomic variabla with atomic_read.
Note that the entire check is racy anyway and purely informational.
Also update it to reflect the forcewake voodoo changes, the kernel can
now also hold onto a forcewake reference for longer times.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
If GPU lockup is detected in ib_pool get we are holding the ib_pool
mutex that will be needed by the GPU reset code. As ib_pool code is
safe to be reentrant from GPU reset code we should not block if we
are trying to get the ib pool lock on the behalf of the same userspace
caller, thus use the radeon_mutex_lock helper.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Silence out the lock dependency warning by moving bo allocation out
of ib mutex protected section. Might lead to useless temporary
allocation but it's not harmful as such things only happen at
initialization.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
If the master tries to authenticate a client using drm_authmagic and
that client has already closed its drm file descriptor,
either wilfully or because it was terminated, the
call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
and corrupt it.
Typically this results in a hard system hang.
This patch fixes that problem by removing any authentication tokens
(struct drm_magic_entry) open for a file descriptor when that file
descriptor is closed.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Corresponding changes to improve our error_state are pending
some other patches to clean up things first.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
We need this to correctly access registers in the gt power well from
userspace.
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: stable@vger.kernel.org
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
We had two things in a row claiming to be RC6.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
GMA500 did it the old way and it's been on the TODO list to fix. Current kernels
now blow up if we use the old way so we'd better do the work !
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
HDMI 1.3 defines single link clocks up to 340 Mhz.
Refine the current dual link checks to only enable
dual link for DVI > 165 Mhz or HDMI > 340 Mhz if the
hw supports HDMI 1.3 (DCE3+).
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44755
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We were previously just checking for audio.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
dig transmitter control table only has ENABLE/DISABLE actions
on DCE4.1/DCE5.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44955
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Needs to happen earlier in the mode set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
We really only need to set it up once on init or resume
rather than on every mode set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Return a number of bytes read in radeon_atrm_get_bios_chunk() and
properly check this value in radeon_atrm_get_bios().
If radeon_atrm_get_bios_chunk() read less bytes then were requested,
it means that it finished reading bios data.
Prior to this patch, condition in radeon_atrm_get_bios() was always
equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false,
thus radeon_atrm_get_bios() was trying to read past the bios data
wasting boot time.
On my lenovo ideapad u455 laptop this patch drops bios reading time
from ~5.5s to ~1.5s.
Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
At a boot time I observed following bug:
BUG: unable to handle kernel paging request at ffff8800a4244000
IP: [<ffffffff81275b5b>] memcpy+0xb/0x120
PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU 0
Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+)
mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi
joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc
loop btrfs
Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046 /AMD CRB
RIP: 0010:[<ffffffff81275b5b>] [<ffffffff81275b5b>] memcpy+0xb/0x120
RSP: 0018:ffff8800aa72db00 EFLAGS: 00010246
RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087
RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8
RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec
R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000
R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800
FS: 00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000)
Stack:
ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28
ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020
ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000
Call Trace:
[<ffffffffa04e7c7b>] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
[<ffffffff8113cbef>] ? kmalloc_order_trace+0x3f/0xb0
[<ffffffffa04a9298>] radeon_get_bios+0x68/0x2f0 [radeon]
[<ffffffffa04c7a30>] rv770_init+0x40/0x280 [radeon]
[<ffffffffa047d740>] radeon_device_init+0x560/0x600 [radeon]
[<ffffffffa047ef4f>] radeon_driver_load_kms+0xaf/0x170 [radeon]
[<ffffffffa043cdde>] drm_get_pci_dev+0x18e/0x2c0 [drm]
[<ffffffffa04e7e95>] radeon_pci_probe+0xad/0xb5 [radeon]
[<ffffffff81296c5f>] local_pci_probe+0x5f/0xd0
[<ffffffff81297418>] pci_device_probe+0x88/0xb0
[<ffffffff813417aa>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff813418d8>] really_probe+0x68/0x180
[<ffffffff81341be5>] driver_probe_device+0x45/0x70
[<ffffffff81341cb3>] __driver_attach+0xa3/0xb0
[<ffffffff81341c10>] ? driver_probe_device+0x70/0x70
[<ffffffff813400ce>] bus_for_each_dev+0x5e/0x90
[<ffffffff8134172e>] driver_attach+0x1e/0x20
[<ffffffff81341298>] bus_add_driver+0xc8/0x280
[<ffffffff813422c6>] driver_register+0x76/0x140
[<ffffffff812976d6>] __pci_register_driver+0x66/0xe0
[<ffffffffa043d021>] drm_pci_init+0x111/0x120 [drm]
[<ffffffff8133c67a>] ? vga_switcheroo_register_handler+0x3a/0x60
[<ffffffffa0229000>] ? 0xffffffffa0228fff
[<ffffffffa02290ec>] radeon_init+0xec/0xee [radeon]
[<ffffffff810002f2>] do_one_initcall+0x42/0x180
[<ffffffff8109d8d2>] sys_init_module+0x92/0x1e0
[<ffffffff815407a9>] system_call_fastpath+0x16/0x1b
Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 <f3> 48
a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
RIP [<ffffffff81275b5b>] memcpy+0xb/0x120
RSP <ffff8800aa72db00>
CR2: ffff8800a4244000
---[ end trace fcffa1599cf56382 ]---
Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
on my system it can return 2048 bytes chunk, so pass the length of
retrieved chunk to memcpy(), not the length of the recieving buffer.
Signed-off-by: Igor Murzov <e-mail@date.by>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
