On Fri, Oct 21, 2022 at 11:32:01PM +0100, Conor Dooley wrote: > On Fri, Oct 21, 2022 at 11:05:40PM +0100, Lad, Prabhakar wrote: > > Hi Rob, > > > > Thank you for the review. > > > > On Fri, Oct 21, 2022 at 3:05 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > > > > > On Wed, Oct 19, 2022 at 11:02:42PM +0100, Prabhakar wrote: > > > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > > > > > > > On the AX45MP core, cache coherency is a specification option so it may > > > > not be supported. In this case DMA will fail. As a workaround, firstly we > > > > allocate a global dma coherent pool from which DMA allocations are taken > > > > and marked as non-cacheable + bufferable using the PMA region as specified > > > > in the device tree. Synchronization callbacks are implemented to > > > > synchronize when doing DMA transactions. > > > > > > > > The Andes AX45MP core has a Programmable Physical Memory Attributes (PMA) > > > > block that allows dynamic adjustment of memory attributes in the runtime. > > > > It contains a configurable amount of PMA entries implemented as CSR > > > > registers to control the attributes of memory locations in interest. > > > > > > > > Below are the memory attributes supported: > > > > * Device, Non-bufferable > > > > * Device, bufferable > > > > * Memory, Non-cacheable, Non-bufferable > > > > * Memory, Non-cacheable, Bufferable > > > > * Memory, Write-back, No-allocate > > > > * Memory, Write-back, Read-allocate > > > > * Memory, Write-back, Write-allocate > > > > * Memory, Write-back, Read and Write-allocate > > > > > > > > This patch adds support to configure the memory attributes of the memory > > > > regions as passed from the l2 cache node and exposes the cache management > > > > ops. > > > > > > > > More info about PMA (section 10.3): > > > > http://www.andestech.com/wp-content/uploads/AX45MP-1C-Rev.-5.0.0-Datasheet.pdf > > > > > > > > This feature is based on the work posted [0] by Vincent Chen > > > > <vincentc@xxxxxxxxxxxxx> for the Andes AndeStart RISC-V CPU. > > > > > > > > [0] https://lore.kernel.org/lkml/1540982130-28248-1-git-send-email-vincentc@xxxxxxxxxxxxx/ > > > > > > > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@xxxxxxxxxxxxxx> > > > > --- > > > > arch/riscv/include/asm/cacheflush.h | 8 + > > > > arch/riscv/include/asm/errata_list.h | 2 + > > > > arch/riscv/mm/dma-noncoherent.c | 20 ++ > > > > drivers/soc/renesas/Kconfig | 5 + > > > > drivers/soc/renesas/Makefile | 4 + > > > > drivers/soc/renesas/rzf/Kconfig | 6 + > > > > drivers/soc/renesas/rzf/Makefile | 3 + > > > > drivers/soc/renesas/rzf/ax45mp_cache.c | 431 +++++++++++++++++++++++++ > > > > > > How many cache drivers do we have around now? I've seen a few bindings > > > go by. I'm guessing it is time to stop putting the drivers in the > > > drivers/soc/ dumping ground. > > > > > The main reason this driver is not in arch/riscv is that it has vendor > > specific extensions. Due to this reason it was agreed during the LPC > > that vendor specific extension should be maintained by SoC vendors and > > was agreed that this can go into drivers/soc/renesas folder instead. > > Does not in drivers/soc mean they need to go into arch/riscv? > The outcome of the chat at the LPC BoF was more that the cache drivers > themselves should not be be routed via the arch maintainers, no? drivers/cache/ or something is what I'm suggesting starting. The first thing is probably making an inventory of how many we already have. Rob
