- 06 Apr, 2016 40 commits
-
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by:
Tom St Denis <tom.stdenis@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 092c96a8) Signed-off-by:
Alberto Milone <alberto.milone@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Need to properly handle the max link rate in the dpcd. This prevents some cases where 5.4 Ghz is selected when it shouldn't be. v2: simplify logic, add array bounds check Reviewed-by:
-
Matt Roper authored
BugLink: http://bugs.launchpad.net/bugs/1546572 pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the legacy FB fields (plane->fb and plane->old_fb). However it was building the plane mask to pass to this function incorrectly (the bitwise OR was using plane indices rather than plane masks). The end result was that sometimes the legacy pointers would become out of sync with the atomic pointers. If another operation tried to re-set the same FB onto the plane, we might end up with the pointers back in sync, but improper reference counts, which would eventually lead to system crashes when we accessed a pointer to a prematurely-destroyed FB. The cause here was a very subtle bug introduced in commit: commit 07d3bad6 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed Nov 11 11:29:11 2015 +0100 drm/core: Fix old_fb handling in pan_display_atomic. I found the crashes were most easily reproduced (on i915 at least) by starting X and then VT switching to a VT that wasn't running a console instance...the sequence of vt/fbcon entries that happen in that case trigger a reference count mismatch and crash the system. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 7118fd9b) Signed-off-by:
-
Nicolai Hähnle authored
BugLink: http://bugs.launchpad.net/bugs/1546572 In the rare situation where the kmalloc fails we're probably screwed anyway, but let's try to be more robust about it. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
Nicolai Hähnle <Nicolai.Haehnle@amd.com> Signed-off-by:
-
Thierry Reding authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Commit 88e72717 ("drm/irq: Use unsigned int pipe in public API") updated the prototype of this function but not the implementation. This wasn't noticed even through compile tests because the prototype is part of the source file that uses it and hence the compiler won't know the prototype when it compiles the implementation. The right thing would've been to move the prototype to a header that's included in radeon_kms.c so that the implementation signature could be checked against it, but the closest thing would've been radeon_drv.h and including that results in a lot of build errors, so we'll leave it as is for now. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Christian König authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This avoids allocating it on the fly. v2: fix grammar in comment Signed-off-by:
Chunming Zhou <david1.zhou@amd.com> (cherry picked from commit ee1782c3) Signed-off-by:
-
Christian König authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This way we avoid the extra allocation for the page directory entry. Signed-off-by:
-
Christian König authored
BugLink: http://bugs.launchpad.net/bugs/1546572 They share the reservation object with the page directory anyway. Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 In some cases the amount of vram may be less than the BAR size, if so, limit visible vram to the amount of actual vram, not the BAR size. Reviewed-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Change the default scheduler queue size from 16 to 32. Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Properly handle ctx init failure. Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 umd somtimes will create a context for every ring, that means some entities wouldn't be used at all. Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Add more fine grained debugging output for init/fini/suspend/ resume failures. Signed-off-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Change-Id: I2ae9bb4a929f7c0c8783e0be563ae04be77596e2 Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Use default value as a base. Signed-off-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Otherwise FW cannot see the RLC ACK for the memory clean request It's for Stoney. Signed-off-by:
-
Chunming Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Allows us to set priorities in the scheduler. Signed-off-by:
Junwei Zhang <Jerry.Zhang@amd.com> (cherry picked from commit d033a6de) Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This adds EDC support for CZ. EDC = Error Correction and Detection This code properly initializes the EDC hardware and resets the error counts. This is done in late_init since it requires the IB pool which is not initialized during hw_init. v2: fix the IB size as noted by Felix, fix shader pgm register programming v3: use the IB for the shaders as suggested by Christian Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 EDC is a RAS feature for on chip memory. Reviewed-by:
-
Daniel Vetter authored
BugLink: http://bugs.launchpad.net/bugs/1546572 For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
BugLink: http://bugs.launchpad.net/bugs/1546572 For drm_gem_object_unreference callers are required to hold dev->struct_mutex, which these paths don't. Enforcing this requirement has become a bit more strict with commit ef4c6270 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 09:36:25 2015 +0200 drm/gem: Check locking in drm_gem_object_unreference Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
monk.liu authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios directly from the rom. In some cases, e.g., virtualization, the rom is not available via the BAR or other means. Access it directly. This is an updated version of Monks original patch which uses family specific callbacks and unifies some of the validation checking. Reviewed-by:
Monk Liu <Monk.Liu@amd.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios image directly from the rom. Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 Read the vbios image directly from the rom. Reviewed-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This is necessary when the vbios image is not directly accessible via the rom BAR or legacy vga location. Reviewed-by:
-
Julia Lawall authored
BugLink: http://bugs.launchpad.net/bugs/1546572 The radeon_asic_ring structures are never modified, so declare them as const. Done with the help of Coccinelle. Reviewed-by:
Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by:
-
Jammy Zhou authored
BugLink: http://bugs.launchpad.net/bugs/1546572 This can solve the path problem when compile amdgpu with DKMS. v2: agd: rebase on current drm-next Signed-off-by:
-
Alberto Milone authored
BugLink: http://bugs.launchpad.net/bugs/1546572Signed-off-by:
-
Huy Nguyen authored
BugLink: http://bugs.launchpad.net/bugs/1552632 problem description: The current code sets UAR page size equal to system page size. The ConnectX-3 and ConnectX-3 Pro HWs require minimum 128 UAR pages. The mlx4 kernel drivers are not loaded if there is less than 128 UAR pages. solution: Always set UAR page to 4KB. This allows more UAR pages if the OS has PAGE_SIZE larger than 4KB. For example, PowerPC kernel use 64KB system page size, with 4MB uar region, there are 4MB/2/64KB = 32 uars (half for uar, half for blueflame). This does not meet minimum 128 UAR pages requirement. With 4KB UAR page, there are 4MB/2/4KB = 512 uars which meet the minimum requirement. Note that only codes in mlx4_core that deal with firmware know that uar page size is 4KB. Codes that deal with usr page in cq and qp context (mlx4_ib, mlx4_en and part of mlx4_core) still have the same assumption that uar page size equals to system page size. Note that with this implementation, on 64KB system page size kernel, there are 16 uars per system page but only one uars is used. The other 15 uars are ignored because of the above assumption. Regarding SR-IOV, mlx4_core in hypervisor will set the uar page size to 4KB and mlx4_core code in virtual OS will obtain the uar page size from firmware. Regarding backward compatibility in SR-IOV, if hypervisor has this new code, the virtual OS must be updated. If hypervisor has old code, and the virtual OS has this new code, the new code will be backward compatible with the old code. If the uar size is big enough, this new code in VF continues to work with 64 KB uar page size (on PowerPc kernel). If the uar size does not meet 128 uars requirement, this new code not loaded in VF and print the same error message as the old code in Hypervisor. Signed-off-by:
Huy Nguyen <huyn@mellanox.com> Reviewed-by:
Yishai Hadas <yishaih@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 85743f1e) Signed-off-by:
-
Tim Gardner authored
Ignore: yes Signed-off-by: -
Tim Gardner authored
Signed-off-by: -
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1553179Signed-off-by:
-
Stefan Bader authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 8d16ce54 upstream. Added a safeguard in the shutdown case. At least while not being attached it is also possible to trigger a kernel bug by writing into writeback_running. This change adds the same check before trying to wake up the thread for that case. Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Cc: Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 This reverts commit 6ac65b6e. Revert in favor of upstream stable. Signed-off-by:
-
Luca Coelho authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 5e56276e upstream. The firmware can perform a scheduled scan with not matchsets passed, but it can't send notification that results were found. Since the userspace then cannot know when we got new results and the firmware wouldn't trigger a wake in case we are sleeping, it's better not to allow scans without matchsets. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=110831Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Oren Givon authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 006bda75 upstream. Update and fix some 7265 PCI IDs entries. Signed-off-by:
Oren Givon <oren.givon@intel.com> Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 62d7476d upstream. 8000 device family has a new debug engine that needs to be configured differently than 7000's. The debug engine's DMA works in chunks of memory and the size of the buffer really means the start of the last chunk. Since one chunk is 256-byte long, we should configure the device to write to buffer_size - 256. This fixes a situation were the device would write to memory it is not allowed to access. Signed-off-by:
-
Emmanuel Grumbach authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit a1cdb1c5 upstream. My commit below introduced a mutex in the transport to prevent concurrent operations. To do so, it added a flag (is_down) to make sure the transport is in the right state. This uncoverred an bug that didn't cause any harm until now: iwldvm calls stop_device and then starts the firmware without calling start_hw in between. While this flow is fine from the device configuration point of view (register, etc...), it is now forbidden by the new is_down flag. This led to this error to appear: iwlwifi 0000:05:00.0: Can't start_fw since the HW hasn't been started and the suspend would fail. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=109591Reported-by:
Bogdan Bogush <bogdan.s.bogush@gmail.com> Fixes=fa9f3281 ("iwlwifi: pcie: lock start_hw / start_fw / stop_device") Signed-off-by:
-
