From mboxrd@z Thu Jan 1 00:00:00 1970 From: robin.murphy@arm.com (Robin Murphy) Date: Mon, 30 Jan 2017 15:31:26 +0000 Subject: [PATCH 06/10] soc/qbman: Add ARM equivalent for flush_dcache_range() In-Reply-To: <1485570872.9266.22.camel@buserror.net> References: <1484779180-1344-1-git-send-email-roy.pledge@nxp.com> <5414359.8GMja3pNrI@wuerfel> <1485570872.9266.22.camel@buserror.net> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 28/01/17 02:34, Scott Wood wrote: > On Fri, 2017-01-27 at 17:41 +0100, Arnd Bergmann wrote: >> On Thu, Jan 26, 2017 at 6:08 AM, Scott Wood wrote: >>> >>> On 01/25/2017 03:20 PM, Arnd Bergmann wrote: >>>> >>>> On Monday, January 23, 2017 7:24:59 PM CET Roy Pledge wrote: >>> >>>> >>>> If this is normal RAM, you should be able to just write zeroes, and then >>>> do a dma_map_single() for initialization. >>> The DMA API on PPC currently has no way of knowing that the device >>> accesses this memory incoherently. >> Ah, this is because PPC doesn't use the 'dma-coherent' property on devices >> but just assumes that coherency is a global property of the platform,right? > > Right. > >>> If that were somehow fixed, we still couldn't use dma_map_single() as it >>> doesn't accept virtual addresses that come from memremap() or similar >>> dynamic mappings. We'd have to convert the physical address to an array >>> of struct pages and pass each one to dma_map_page(). >> Sorry for my ignorance, but where does the memory come from to start >> with? Is this in the normal linearly mapped RAM, in a carveout outside >> of the linear mapping but the same memory, or in some on-chip buffer? > > It's RAM that comes from the device tree reserved memory mechanism > (drivers/of/of_reserved_mem.c). On a 32-bit kernel it is not guaranteed (or > likely) to be lowmem. Wouldn't dma_declare_coherent_memory() be the appropriate tool for that job, then (modulo the PPC issue)? On ARM that should result in dma_alloc_coherent() giving back a non-cacheable mapping if the device is non-coherent, wherein a dmb_wmb() after writing the data from the CPU side should be enough to ensure it is published to the device. Robin. >>> And even if we did all that, there would still be other manual cache >>> manipulation left in this driver, to deal with its cacheable register >>> interface. >> I thought we had concluded that "cacheable register" is something >> that cannot work reliably on ARM at all when this came up before. >> Any updates on that? > > I'm not familiar with the details there... My understanding is that the > hardware people at NXP are convinced that it can work on these specific chips > due to implementation details. > > -Scott > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >