linux-dev/arch/csky/mm/ioremap.c, branch linus/master

csky: use generic ioremap

2019-11-12T10:37:52Z

Use the generic ioremap_prot and iounmap helpers. Signed-off-by: Christoph Hellwig Acked-by: Guo Ren

csky: remove ioremap_cache

2019-11-11T20:18:20Z

No driver that can be used on csky uses ioremap_cache, and this interface has been deprecated in favor of memremap. Signed-off-by: Christoph Hellwig Acked-by: Guo Ren

csky: Fixup ioremap function losing

2019-08-15T11:21:28Z

Implement the following apis to meet usage in different scenarios. - ioremap (NonCache + StrongOrder) - ioremap_nocache (NonCache + StrongOrder) - ioremap_wc (NonCache + WeakOrder ) - ioremap_cache ( Cache + WeakOrder ) Also change flag VM_ALLOC to VM_IOREMAP in get_vm_area_caller. Signed-off-by: Guo Ren Cc: Arnd Bergmann Cc: Christoph Hellwig

csky: Fixup dma_alloc_coherent with PAGE_SO attribute

2019-07-31T03:05:25Z

This bug is from commit: 2b070ccdf8c0 (fixup abiv2 mmap(... O_SYNC) failed). In that patch we remove the _PAGE_SO for memory noncache mapping and this will cause problem when drivers use dma descriptors to control the transcations without dma_w/rmb(). After referencing other archs' implementation, pgprot_writecombine is introduced for mmap(... O_SYNC). Signed-off-by: Guo Ren

csky: Fixup io-range page attribute for mmap("/dev/mem")

2019-02-13T01:48:14Z

Some user space drivers need accessing IO address and IO remap need SO(strong order) page-attribute to make IO operation correct. So we need add SO-page-attr for all non-memory address. Signed-off-by: Guo Ren Reported-by: Fan Xiaodong

csky: fixup abiv2 mmap(... O_SYNC) failed.

2018-12-31T02:56:45Z

Glibc function mmap(... O_SYNC) will make page to _PAGE_UNCACHE + _PAGE_SO and strong-order page couldn't support unalignment access. So remove _PAGE_SO from _PAGE_UNCACHE, also sync abiv1 with the macro of _PAGE_SO. Signed-off-by: Guo Ren Reported-by: Liu Renwei Tested-by: Yuan Qiyun

csky: MMU and page table management

2018-10-25T15:36:19Z

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 Cc: Christoph Hellwig Reviewed-by: Arnd Bergmann