Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops

On Thu, May 18 2017, Lukas Wunner wrote: > Reported-by: Nicolai Stange <nicsta...@gmail.com> > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with > vga_switcheroo") > Signed-off-by: Lukas Wunner <lu...@wunner.de> > --- > > Awaitin

[REGRESSION] drm/radeon: Don't register Thunderbolt eGPU with vga_switcheroo

Hi, I'm experiencing a boot failure on next-20170515: BUG: unable to handle kernel NULL pointer dereference at 07cb IP: radeon_driver_load_kms+0xeb/0x230 [radeon] PGD 0 P4D 0 Oops: [#1] SMP Modules linked in: amdkfd amd_iommu_v2 i915(+) radeon(+) i2c_algo_bit

[REGRESSION] drm/i915: Wait for all engines to be idle as part of i915_gem_wait_for_idle()

Hi, my system (always) locks up when booting a next-20170515 kernel. No oops. Sending magic sysrqs over serial doesn't cause any reaction. Last few console messages before death are: [7.089221] Console: switching to colour frame buffer device 128x48 [7.101470] radeon :01:00.0:

[PATCH] drm/amdgpu: don't add files at control minor debugfs directory

ix this by omitting the drm_debugfs_create_files() call for the control minor debugfs directory which is now non-existent anyway. Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange --- Applicable to next-20161202. Compile-only tested. drivers/gpu/drm/amd/amdgpu/amdgp

[PATCH] drm/radeon: don't add files at control minor debugfs directory

Christian König writes: > Am 05.12.2016 um 08:27 schrieb Daniel Vetter: >> On Sat, Dec 03, 2016 at 03:47:00PM +0100, Nicolai Stange wrote: >>> Since commit 8a357d10043c ("drm: Nerf DRM_CONTROL nodes"), a >>> struct drm_device's ->control me

[PATCH] drm/radeon: don't add files at control minor debugfs directory

create_files() call for the control minor debugfs directory which is now non-existent anyway. Fixes: 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") Signed-off-by: Nicolai Stange --- Tested on top of next-20161202. That 8a357d10043c ("drm: Nerf DRM_CONTROL nodes") is in next since 20161201.

[PATCH v3] drm/radeon: don't include RADEON_HPD_NONE in HPD IRQ enable bitsets

into the 'enabled' bitset in the *_init()- or the 'disabled' bitset in the *_fini()-functions respectively. Signed-off-by: Nicolai Stange --- Applicable to linux-next-20160322. WARNING: Apart from compilation, the changes to r100.c, r600.c and rs600.c are untested! v2 thread can be

[PATCH v2] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

Alex Deucher writes: > On Mon, Mar 21, 2016 at 8:10 AM, Nicolai Stange > wrote: >> The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id >> enum transform 1:1 into bit positions within the 'enabled' bitset as >> assembled by evergreen_hpd_init

[PATCH v2] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

RADEON_MAX_HPD_PINS. Thus, this patch is a cosmetic one. All of the above applies analogously to evergreen_hpd_fini(). Silence UBSAN by checking ->hpd.hpd for RADEON_HPD_NONE before oring it into the 'enabled' bitset in evergreen_hpd_init() or the 'disabled' bitset in evergreen_hpd_fini() resp

[PATCH] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

Nicolai Stange writes: > The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id > enum transform 1:1 into bit positions within the 'enabled' bitset as > assembled by evergreen_hpd_init(): > > enabled |= 1 << radeon_connector->hpd.hpd; > > However,

[PATCH] drm/radeon: evergreen_hpd_init()/_fini(): fix HPD IRQ bitset

ly. Signed-off-by: Nicolai Stange --- Applicable to linux-next-20160318. drivers/gpu/drm/radeon/evergreen.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 76c4bdf..6360717 100644 --- a/drivers