- 06 Apr, 2016 40 commits
-
-
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 <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Chunming Zhou <david1.zhou@amd.com> (cherry picked from commit 56467ebf) Signed-off-by:
Alberto Milone <alberto.milone@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
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:
-
Matan Barak authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 64936773 upstream. cma_validate_port wrongly assumed that Ethernet devices are RoCE devices and thus their ndev should be matched in the GID table. This broke the iWarp support. Fixing that matching the ndev only if we work on a RoCE port. Cc: <stable@vger.kernel.org> # 4.4.x- Fixes: abae1b71 ('IB/cma: cma_validate_port should verify the port and netdevice') Reported-by:
Hariprasad Shenai <hariprasad@chelsio.com> Tested-by:
Matan Barak <matanb@mellanox.com> Reviewed-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 98229aa3 upstream. We still can end up with a stale vector due to the following: CPU0 CPU1 CPU2 lock_vector() data->move_in_progress=0 sendIPI() unlock_vector() set_affinity() assign_irq_vector() lock_vector() handle_IPI move_in_progress = 1 lock_vector() unlock_vector() move_in_progress == 1 So we need to serialize the vector assignment against a pending cleanup. The solution is rather simple now. We not only check for the move_in_progress flag in assign_irq_vector(), we also check whether there is still a cleanup pending in the old_domain cpumask. If so, we return -EBUSY to the caller and let him deal with it. Though we have to be careful in the cpu unplug case. If the cleanout has not yet completed then the following setaffinity() call would return -EBUSY. Add code which prevents this. Full context is here: http://lkml.kernel.org/r/5653B688.4050809@stratus.comReported-and-tested-by:
Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
Borislav Petkov <bp@alien8.de> Cc: Jiang Liu <jiang.liu@linux.intel.com> Cc: Jeremiah Mahler <jmmahler@gmail.com> Cc: andy.shevchenko@gmail.com Cc: Guenter Roeck <linux@roeck-us.net> Link: http://lkml.kernel.org/r/20151231160107.207265407@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 90a2282e upstream. First of all there is no point in looking up the irq descriptor again, but we also need the descriptor for the final cleanup race fix in the next patch. Make that change seperate. No functional difference. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 56d7d2f4 upstream. We want to synchronize new vector assignments with a pending cleanup. Remove a dying cpu from a pending cleanup mask. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit 5da0c121 upstream. There is no need to allocate a new cpumask for sending the cleanup vector. The old_domain mask is now protected by the vector_lock, so we can safely remove the offline cpus from it and send the IPI with the resulting mask. Signed-off-by:
-
Thomas Gleixner authored
BugLink: http://bugs.launchpad.net/bugs/1553179 commit c1684f50 upstream. send_cleanup_vector() fiddles with the old_domain mask unprotected because it relies on the protection by the move_in_progress flag. But this is fatal, as the flag is reset after the IPI has been sent. So a cpu which receives the IPI can still see the flag set and therefor ignores the cleanup request. If no other cleanup request happens then the vector stays stale on that cpu and in case of an irq removal the vector still persists. That can lead to use after free when the next cleanup IPI happens. Protect the code with vector_lock and clear move_in_progress before sending the IPI. This does not plug the race which Joe reported because: CPU0 CPU1 CPU2 lock_vector() data->move_in_progress=0 sendIPI() unlock_vector() set_affinity() assign_irq_vector() lock_vector() handle_IPI move_in_progress = 1 lock_vector() unlock_vector() move_in_progress == 1 The full fix comes with a later patch. Reported-and-tested-by:
-
