Hi Linus,
please pull the folowing batch of updates for the Xtensa architecture
for 4.19.
The following changes since commit 1ffaddd029c867d134a1dde39f540dcc8c52e274:
Linux 4.18-rc8 (2018-08-05 12:37:41 -0700)
are available in the git repository at:
git://github.com/jcmvbkbc/linux-xtensa.git tags/xtensa-20180820
for you to fetch changes up to 35d231db53a60b76e218a56da30ad071d4717b56:
Merge branch 'xtensa-dma-fixes' (early part) into xtensa-fixes (2018-08-20 13:24:24 -0700)
----------------------------------------------------------------
Xtensa improvements for v4.19:
- switch xtensa arch to the generic noncoherent direct mapping operations;
- add support for DMA_ATTR_NO_KERNEL_MAPPING attribute;
- clean up users of platform/hardware.h in generic Xtensa code;
- fix assembly cache maintenance code for long cache lines;
- rework noMMU cache attributes initialization;
- add big-endian HiFi2 test_kc705_be CPU variant.
----------------------------------------------------------------
Christoph Hellwig (1):
xtensa: use generic dma_noncoherent_ops
Max Filippov (14):
xtensa: support DMA_ATTR_NO_KERNEL_MAPPING attribute
xtensa: platform-specific handling of coherent memory
xtensa: limit offsets in __loop_cache_{all,page}
xtensa: increase ranges in ___invalidate_{i,d}cache_all
xtensa: rework noMMU cache attributes initialization
xtensa: drop unused {CONFIG,PLATFORM}_DEFAULT_MEM_SIZE
xtensa: rework {CONFIG,PLATFORM}_DEFAULT_MEM_START
xtensa: move PLATFORM_NR_IRQS to Kconfig
xtensa: drop unneeded platform/hardware.h headers
xtensa: drop variant IRQ support
xtensa: make bootparam parsing optional
xtensa: clean up boot-elf/bootstrap.S
xtensa: add test_kc705_be variant
Merge branch 'xtensa-dma-fixes' (early part) into xtensa-fixes
arch/xtensa/Kconfig | 60 ++-
arch/xtensa/boot/boot-elf/bootstrap.S | 19 +-
arch/xtensa/configs/nommu_kc705_defconfig | 2 +-
arch/xtensa/include/asm/Kbuild | 1 +
arch/xtensa/include/asm/cacheasm.h | 69 ++-
arch/xtensa/include/asm/dma-mapping.h | 26 -
arch/xtensa/include/asm/initialize_mmu.h | 42 +-
arch/xtensa/include/asm/irq.h | 21 +-
arch/xtensa/include/asm/kmem_layout.h | 6 -
arch/xtensa/include/asm/page.h | 5 +-
arch/xtensa/include/asm/pgtable.h | 8 +
arch/xtensa/include/asm/platform.h | 27 +
arch/xtensa/include/asm/processor.h | 1 -
arch/xtensa/include/asm/vectors.h | 1 -
arch/xtensa/kernel/head.S | 2 +
arch/xtensa/kernel/irq.c | 1 -
arch/xtensa/kernel/pci-dma.c | 193 +++----
arch/xtensa/kernel/setup.c | 10 +-
arch/xtensa/kernel/vmlinux.lds.S | 2 +-
.../platforms/iss/include/platform/hardware.h | 29 --
.../platforms/xt2000/include/platform/hardware.h | 11 -
.../platforms/xtfpga/include/platform/hardware.h | 9 -
.../variants/test_kc705_be/include/variant/core.h | 575 +++++++++++++++++++++
.../test_kc705_be/include/variant/tie-asm.h | 308 +++++++++++
.../variants/test_kc705_be/include/variant/tie.h | 182 +++++++
drivers/irqchip/irq-xtensa-mx.c | 2 -
drivers/irqchip/irq-xtensa-pic.c | 2 -
27 files changed, 1300 insertions(+), 314 deletions(-)
delete mode 100644 arch/xtensa/include/asm/dma-mapping.h
delete mode 100644 arch/xtensa/platforms/iss/include/platform/hardware.h
create mode 100644 arch/xtensa/variants/test_kc705_be/include/variant/core.h
create mode 100644 arch/xtensa/variants/test_kc705_be/include/variant/tie-asm.h
create mode 100644 arch/xtensa/variants/test_kc705_be/include/variant/tie.h
Thanks.
-- Max
> xtensa: platform-specific handling of coherent memory
How is this supposed to be used? For the nommu version there only
are __weak stubs, but no actual implementation.
On Thu, Aug 23, 2018 at 8:21 AM, Christoph Hellwig <[email protected]> wrote:
>> xtensa: platform-specific handling of coherent memory
>
> How is this supposed to be used? For the nommu version there only
> are __weak stubs, but no actual implementation.
The idea is that nommu xtensa platforms that have two views of the
physical memory may map one of them as cached and the other as
uncached. They will provide implementations for these four functions.
A platform with single view of the physical memory but with CPU that
has region translation still may create two views of the memory.
Both situations are platform-specific as we don't have fixed address
space layout for nommu systems.
I had an example here, but the addresses in this example are incorrect
as I misread the spec, so I didn't add it to the PR:
https://github.com/jcmvbkbc/linux-xtensa/commit/21ec04090f59647e69fb775ae9d447fcc778701e
--
Thanks.
-- Max