History log of /linux-master/arch/csky/mm/dma-mapping.c
Revision Date Author Comments
# cfb24463 14-Feb-2022 Deyan Wang <wonder_rock@126.com>

csky: Fix versioncheck warnings

$make versioncheck

arch/csky/include/asm/io.h: 8 linux/version.h not needed.
arch/csky/kernel/process.c: 5 linux/version.h not needed.
arch/csky/mm/dma-mapping.c: 12 linux/version.h not needed.

comments from Randy:

The patch makes sense but these are not compile warnings.
They come from scripts/checkversion.pl, which can be called
by 'make versioncheck', so I suppose that something in your
build system is running 'make versioncheck'.

Signed-off-by: Deyan Wang <wonder_rock@126.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Guo Ren <guoren@kernel.org>


# 9f4df96b 22-Sep-2020 Christoph Hellwig <hch@lst.de>

dma-mapping: merge <linux/dma-noncoherent.h> into <linux/dma-map-ops.h>

Move more nitty gritty DMA implementation details into the common
internal header.

Signed-off-by: Christoph Hellwig <hch@lst.de>


# 0b1abd1f 11-Sep-2020 Christoph Hellwig <hch@lst.de>

dma-mapping: merge <linux/dma-contiguous.h> into <linux/dma-map-ops.h>

Merge dma-contiguous.h into dma-map-ops.h, after removing the comment
describing the contiguous allocator into kernel/dma/contigous.c.

Signed-off-by: Christoph Hellwig <hch@lst.de>


# 56e35f9c 07-Nov-2019 Christoph Hellwig <hch@lst.de>

dma-mapping: drop the dev argument to arch_sync_dma_for_*

These are pure cache maintainance routines, so drop the unused
struct device argument.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>


# 8e3a68fb 02-Aug-2019 Christoph Hellwig <hch@lst.de>

dma-mapping: make dma_atomic_pool_init self-contained

The memory allocated for the atomic pool needs to have the same
mapping attributes that we use for remapping, so use
pgprot_dmacoherent instead of open coding it. Also deduct a
suitable zone to allocate the memory from based on the presence
of the DMA zones.

Signed-off-by: Christoph Hellwig <hch@lst.de>


# ae76f635 30-Jul-2019 Guo Ren <ren_guo@c-sky.com>

csky: Optimize arch_sync_dma_for_cpu/device with dma_inv_range

DMA_FROM_DEVICE only need to read dma data of memory into CPU cache,
so there is no need to clear cache before. Also clear + inv for
DMA_FROM_DEVICE won't cause problem, because the memory range for dma
won't be touched by software during dma working.

Changes for V2:
- Remove clr cache and ignore the DMA_TO_DEVICE in _for_cpu.
- Change inv to wbinv cache with DMA_FROM_DEVICE in _for_device.

Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Arnd Bergmann <arnd@arndb.de>


# 4af9027d 30-Jul-2019 Guo Ren <ren_guo@c-sky.com>

csky/dma: Fixup cache_op failed when cross memory ZONEs

If the paddr and size are cross between NORMAL_ZONE and HIGHMEM_ZONE
memory range, cache_op will panic in do_page_fault with bad_area.

Optimize the code to support the range which cross memory ZONEs.

Changes for V2:
- Revert back to postcore_initcall

Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>


# f04b951f 04-Nov-2018 Christoph Hellwig <hch@lst.de>

csky: use the generic remapping dma alloc implementation

The csky code was largely copied from arm/arm64, so switch to the
generic arm64-based implementation instead.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Guo Ren <ren_guo@c-sky.com>


# 576d0d55 04-Nov-2018 Christoph Hellwig <hch@lst.de>

csky: don't use GFP_DMA in atomic_pool_init

csky does not implement ZONE_DMA, which means passing GFP_DMA is a no-op.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Guo Ren <ren_guo@c-sky.com>


# 013de2d6 05-Sep-2018 Guo Ren <ren_guo@c-sky.com>

csky: MMU and page table management

This patch adds files related to memory management and here is our
memory-layout:

Fixmap : 0xffc02000 – 0xfffff000 (4 MB - 12KB)
Pkmap : 0xff800000 – 0xffc00000 (4 MB)
Vmalloc : 0xf0200000 – 0xff000000 (238 MB)
Lowmem : 0x80000000 – 0xc0000000 (1GB)

abiv1 CPU (CK610) is VIPT cache and it doesn't support highmem.
abiv2 CPUs are all PIPT cache and they could support highmem.

Lowmem is directly mapped by msa0 & msa1 reg, and we needn't setup
memory page table for it.

Link:https://lore.kernel.org/lkml/20180518215548.GH17671@n2100.armlinux.org.uk/
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Cc: Christoph Hellwig <hch@infradead.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>