From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751484AbcFFJIs (ORCPT ); Mon, 6 Jun 2016 05:08:48 -0400 Received: from mout.kundenserver.de ([212.227.17.13]:57522 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbcFFJIp (ORCPT ); Mon, 6 Jun 2016 05:08:45 -0400 From: Arnd Bergmann To: Mark Rutland Cc: Bill Mills , rmk+kernel@armlinux.org.uk, t-kristo@ti.com, ssantosh@kernel.org, catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, r-woodruff2@ti.com, devicetree@vger.kernel.org Subject: Re: [RFC v2 4/4] ARM: keystone: dma-coherent with safe fallback Date: Mon, 06 Jun 2016 11:09:07 +0200 Message-ID: <5480709.cGbSehIKrE@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-22-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160606085627.GA6831@leverpostej> References: <1465183229-24147-1-git-send-email-wmills@ti.com> <1465183229-24147-5-git-send-email-wmills@ti.com> <20160606085627.GA6831@leverpostej> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:3BAAI7/3nfJTe+ZZSMYmxD8Jv7xZ6mqMG8tQ5DIrkVa6pKEFOo6 XDMcBRClkI7+TorLaAsoOtLuDwhNTFdGBd5dw4bKrLzYGkpzFs+ZvibzIw4gSRaLwamzv6M rnV+MDziGEPV9ebgOWtoqnIkJPjNZDxGIg6NlDnAY1qtP4tJQJwjw4YCsXXJg/0abuRh6LD wfCYhUg0iM4t6RcXVmlwQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:NeQ/bQnOYYw=:1iN0RmPqz/cYrw33iyX+gP 8MhoBBeZOvkUJOqtN/42sjRaoIQ14I1loE9b58FAVzLcKDUtnbtY82pjx8XfGbM3YY1H75C6i LAwrIch2Ufvm+SVis01CWvMCnxR2SxW1AVzQ6PGu9SScQHh+CFSz7YqB9upmujFRtUh/qpu7M X8lsRC5c+7nB9BqUUdS4l2LmltytqFd9mQIshbmqexcx8B9vdUJGlMgxG3yeiAM3mMLcayr5p 4rYVnqZ0SFz8XjXgc0/GVNe7IeZWbquEWqeQlneRazgip09yJtOrcO2lXQd4wvoOphIz42mlO 79B62FPJN5T7T4m0cSjw9vlb2zo2WCuFqstNNqWp3oGuOSyvF+Yk9djyFluCHySoRBWu/m2GJ 8zjo7YgOoUwlIOX26zLzFaEVYo98QE4ZKzlg47s/rsOUg8D8bP9G+/BwrT9Av/cwpvG+fK/G1 DdwUEJQf2djOfFytgukPSP5vdd/FsWrz3hdTTcMCMM5ERZrnpRFWgICMbhT4G8FwjWimqO41H /D86HOUUuGPq8ELoMgiRmTQqjkNZsMh74OK9HLzIp5GiRrOG6RF4kMHgubvjLtB5ADWJILuFt JyO76VFApapaMSxmrZQk0s2wF/EipAN2PBRgGesgCHB/xg69nyS2qLIv3C/wLy8FoAlQMVa+U Xptra/HRg3GVcgyre+l6H0Ytv9dSbK9p52KzxaZAOVJsRqbsfJmYkDVq0XGzcZsBkq/zFDDUM b6i3vu9oociuRvZo Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday, June 6, 2016 9:56:27 AM CEST Mark Rutland wrote: > [adding devicetree] > > On Sun, Jun 05, 2016 at 11:20:29PM -0400, Bill Mills wrote: > > Keystone2 can do DMA coherency but only if: > > 1) DDR3A DMA buffers are in high physical addresses (0x8_0000_0000) > > (DDR3B does not have this constraint) > > 2) Memory is marked outer shared > > 3) DMA Master marks transactions as outer shared > > (This is taken care of in bootloader) > > > > Use outer shared instead of inner shared. > > This choice is done at early init time and uses the attr_mod facility > > > > If the kernel is not configured for LPAE and using high PA, or if the > > switch to outer shared fails, then we fail to meet this criteria. > > Under any of these conditions we veto any dma-coherent attributes in > > the DTB. > > I very much do not like this. As I previously mentioned [1], > dma-coherent has de-facto semantics today. This series deliberately > changes that, and inverts the relationship between DT and kernel (as the > describption in the DT would now depend on the configuration of the > kernel). > > I would prefer that we have a separate property (e.g. > "dma-outer-coherent") to describe when a device can be coherent with > Normal, Outer Shareable, Inner Write-Back, Outer Write-Back memory. > Then the kernel can figure out whether or not device can be used > coherently, depending on how it is configured. I share your concern, but I don't think the dma-outer-coherent attribute would be a good solution either. The problem really is that keystone is a platform that is sometimes coherent, depending purely on what kernel we run, and not at all on anything we can describe in devicetree, and I don't see any good way to capture the behavior of the hardware in generic DT bindings. So far, the assumption has been: - when running a non-LPAE kernel, keystone is not coherent, and we must ignore both the dma-coherent properties in devices and the dma-ranges properties in bus nodes. - when running an LPAE kernel, keystone is coherent, and we must respect both of those. My interpretation of Bill's description above is that we now have an additional requirement that at least I was not aware of before, regarding the outer-sharable attribute. I don't think there is much value in making this a boot-time option, since everyone would want to run this platform in a cache-coherent way if at all possible. We already have special hacks to detect the case of keystone running in LPAE mode, in order to do the special rewrite-all-page-tables hack at boot time for relocating the physical address, and we could use the same hack to change the page table attributes. The question is how to communicate the requirement for outer-sharable for a platform. If we think it's a safe assumption that there will not be future 32-bit platforms with this requirement (or maybe one or two more at most), we could leave it in the special keystone hack. Alternatively, a DT property in an appropriate node could indicate that a particular platform requires it. Arnd