From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755267AbbK0UrW (ORCPT ); Fri, 27 Nov 2015 15:47:22 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:50142 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754450AbbK0UrT (ORCPT ); Fri, 27 Nov 2015 15:47:19 -0500 From: Arnd Bergmann To: Catalin Marinas Cc: "Rafael J. Wysocki" , Will Deacon , linux-kernel@vger.kernel.org, Suravee Suthikulpanit , Mark Salter , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC] ARM64: simplify dma_get_ops Date: Fri, 27 Nov 2015 21:46:37 +0100 Message-ID: <7450408.Z6bvbAd5fD@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151127165719.GD25499@e104818-lin.cambridge.arm.com> References: <4270550.cGd11OgA5n@wuerfel> <7483659.O8uXXLFCFD@wuerfel> <20151127165719.GD25499@e104818-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:uw2eDz9KoVorc2dNPhk2YdnjGaq878zevEhlkUWOrWRdUJz2KqK aKkM42rjlP54K+WZzo58/DzTqwARs+r53oczK3J75F59QFGEDuxSgbbFRIxqhgr1Zsns9Ao JZH/wS8njrmhMLEJROd36tNveqBQSNy6Oid9FrR0wTMwUXKu0IqlWmv9hkRehTNk+pddzeo HJJEg3Rfe4lOP5Crix/hg== X-UI-Out-Filterresults: notjunk:1;V01:K0:YUKlspu9mU8=:OiS7i0lZr6+tKRmdl5T6j/ isgy6rMF7p61gMVC2iUH5WDOfCuD0oyeQPAJxdKcmRj/BcvJz8Q9WTE0il4PZi+9XuwAyLj1I 2P/HXVvR1+y6/FUjWzsRWyoIfecq+WGKoPPxgrSn4w3YU5JjSZjeQEPrrTqlmPeWANj2SXrD0 f5xvkHyK2ZXl0DGCzdtaa54jL2dB2ZfiP+JpQx3uhdl9lsr5SniIAko25R5it0v3aczX+wd9z rTmgE0T/UCg/infGPFxDNtmuqEpFAnLs8Dlktw45v2/tfTbcZhynkWGg6hT+hlvHOnEc1+1FH Rj/q/xFos6aWvcmBySNUQ7Ry3VsuQT04EE7x08SaSUm4A080GbDOUgojyCAch8Plvq3Y11Mm8 jF3rUKC4aH6lZNylbABfsVdUe344iK9qIpux1S8iQsF0rR7hMfYytshFnQAj/HapPl05YHGEV HUMOhJJe96BmBbI+g0+NzGLRKOPXBfi2s/P30JwFsEdUfSOzUU6Pf6fo2IWydo50Efpdc5AVl XpaGyJLWaHUlIBoKcllUSmskUHW800+kBTO92fLxYRYxm8GXJKW/wCnem0pLQldt6aozSuJAT NcK0KGPOZvpACFwlNsZVENE7QA8a8/L3nPzJup80uDMBhdfJML+BoTi6RnJeKCHFc6ipBKHN9 5EWgSjf324xe9dba3Sp+rOjomTa9l6xLwV7Yc8/+mG8RPjY5pUc682kdNtSNNJ3C8WRRutdiK MEGfemFJET5cZhQv Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Friday 27 November 2015 16:57:21 Catalin Marinas wrote: > On Tue, Nov 17, 2015 at 01:50:24PM +0100, Arnd Bergmann wrote: > > On Tuesday 17 November 2015 12:22:51 Catalin Marinas wrote: > > > > > The size variable here is the mask that of_dma_configure() computes, > > though it is not a "default": it is whatever the parent bus can support, > > independent of additional restrictions that may be present in the > > device and that are set by the driver. > > > > Checking against that is what I meant above, see below for a prototype > > that I have not even compile-tested and that might be missing some corner > > cases. > > > > We actually have the option of swapping out the dev->dma_ops in set_mask > > so we don't have to go through the swiotlb code for devices that don't > > need it. > > We could indeed have a lighter implementation that only does cache > maintenance but I guess this assumes that the device supports all the > physical address space. Swiotlb detects the masks and doesn't bounce the > buffer unless necessary, so the overhead shouldn't be that large. Right, that part is certainly optional. > > --- a/arch/arm64/mm/dma-mapping.c > > +++ b/arch/arm64/mm/dma-mapping.c > > @@ -341,6 +341,31 @@ static int __swiotlb_get_sgtable(struct device *dev, struct sg_table *sgt, > > return ret; > > } > > > > +static int __swiotlb_set_dma_mask(struct device *dev, u64 mask) > > +{ > > + /* device is not DMA capable */ > > + if (!dev->dma_mask) > > + return -EIO; > > + > > + /* mask is below swiotlb bounce buffer, so fail */ > > + if (!swiotlb_dma_supported(dev, mask)) > > + return -EIO; > > + > > + /* > > + * because of the swiotlb, we can return success for > > + * larger masks, but need to ensure that bounce buffers > > + * are used above parent_dma_mask, so set that as > > + * the effective mask. > > + */ > > + if (mask > dev->dev_archdata.parent_dma_mask) > > + mask = dev->dev_archdata.parent_dma_mask; > > Is there any check for parent_dma_mask being supported by swiotlb? If > not, should we move the mask setting above? I think swiotlb assumes that the bus can always handle all of RAM, as that is typically the case on x86: you can have PCI devices that don't support 64-bit DMA, but the PCI host bridge always does, and there are practically never any DMA masters outside of PCI. powerpc has a 'max_direct_dma_addr' variable in dev_archdata, and we should probably use the same name rather than parent_dma_mask (but note the difference when an offset is involved). On powerpc, we assume that the device driver knows what memory the bus supports, which works because there are fewer SoC vendors reusing the same parts in different ways. The max_direct_dma_addr there appears to only be used for PCI devices. Arnd