| commit | 0ab163ad1ea0bb0ccd4ada2a54834041611d76f1 | |
| author | Abhilash Kesavan <a.kesavan@samsung.com> | |
| Fri, 6 Feb 2015 13:45:28 +0000 (6 19:15 +0530) | ||
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
| Mon, 16 Mar 2015 20:11:32 +0000 (16 21:11 +0100) | ||
| tree | 8e3859e91ef5944990ad7b3555803c4af3891598 | treesnapshot (tar.gz zip) |
| parent | 34644524bce91883d5051a7eaf3ec5464ed149bf | commitdiff |
misc: sram: switch to ioremap_wc from ioremap
Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, the SRAM allocator returns device memory via ioremap.
This causes issues on ARM64 when the internal SoC SRAM allocated by
the generic sram driver is used for audio playback. The destination
buffer address (which is ioremapped SRAM) is not 64-bit aligned for
certain streams (e.g. 44.1k sampling rate). In such cases we get
unhandled alignment faults. Use ioremap_wc in place of ioremap which
gives us normal non-cacheable memory instead of device memory.
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
| drivers/misc/sram.c | diffblobblamehistory |