From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E8A86C47E48 for ; Thu, 26 Sep 2019 10:45:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C85D7207E0 for ; Thu, 26 Sep 2019 10:45:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725912AbfIZKpA (ORCPT ); Thu, 26 Sep 2019 06:45:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:58398 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725813AbfIZKo7 (ORCPT ); Thu, 26 Sep 2019 06:44:59 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 4D89AAFA7; Thu, 26 Sep 2019 10:44:56 +0000 (UTC) Message-ID: <307b988d0c67fb1c42166eca12742bcfda09d92d.camel@suse.de> Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters From: Nicolas Saenz Julienne To: Rob Herring , Robin Murphy Cc: "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, Matthias Brugger , Frank Rowand , linux-arm-msm , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org, xen-devel@lists.xenproject.org, Dan Williams , freedreno , Linux Media Mailing List Date: Thu, 26 Sep 2019 12:44:53 +0200 In-Reply-To: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> <43fb5fe1de317d65a4edf592f88ea150c6e3b8cc.camel@suse.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-spHfnjbbIi+e7UZn+wYh" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org --=-spHfnjbbIi+e7UZn+wYh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > > Robin, have you looked into supporting multiple dma-ranges? It's th= e > > > > next thing > > > > we need for BCM STB's PCIe. I'll have a go at it myself if nothing = is in > > > > the > > > > works already. > > >=20 > > > Multiple dma-ranges as far as configuring inbound windows should work > > > already other than the bug when there's any parent translation. But i= f > > > you mean supporting multiple DMA offsets and masks per device in the > > > DMA API, there's nothing in the works yet. Sorry, I meant supporting multiple DMA offsets[1]. I think I could still ma= ke it with a single DMA mask though. > > There's also the in-between step of making of_dma_get_range() return a > > size based on all the dma-ranges entries rather than only the first one > > - otherwise, something like [1] can lead to pretty unworkable default > > masks. We implemented that when doing acpi_dma_get_range(), it's just > > that the OF counterpart never caught up. >=20 > Right. I suppose we assume any holes in the ranges are addressable by > the device but won't get used for other reasons (such as no memory > there). However, to be correct, the range of the dma offset plus mask > would need to be within the min start and max end addresses. IOW, > while we need to round up (0xa_8000_0000 - 0x2c1c_0000) to the next > power of 2, the 'correct' thing to do is round down. IIUC I also have this issue on my list. The RPi4 PCIe block has an integrat= ion bug that only allows DMA to the lower 3GB. With dma-ranges of size 0xc000_0= 000 you get a 32bit DMA mask wich is not what you need. So far I faked it in th= e device-tree but I guess it be better to add an extra check in of_dma_configure(), decrease the mask and print some kind of warning statin= g that DMA addressing is suboptimal. Regards, Nicolas [1] https://lkml.org/lkml/2018/9/19/641 --=-spHfnjbbIi+e7UZn+wYh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEErOkkGDHCg2EbPcGjlfZmHno8x/4FAl2MlqUACgkQlfZmHno8 x/6+gwgAlzKCB9vN8cCZUfRnnPT+EcYA2/s3oFjf1ar+/e5UsMfCNI5W7cJaKzg9 w0PGZ5VKk5N0wpkGIpUjOYQ9J5PFZwu5bqsce0zWywlRlYCexKvzpQfkplWi0JuI cVAt9Sw5mle+ppW+x9T5UlBcHoCByuQDG9ga44Z7O4jrk/lIp7vK2fmSN3hIEcHV gUPxojWighnxCu+5COgwa182Ncfo3tTLw39oV8uiLOzxXxVkprxdxQHakXPoyg1o WH0OvR09u1lXZAQ1qKtOxHNgKcrNzpr69VBUL/WYvrSqKdg0EI8QRmkByk5cYgrC ztco//83y3fCRh8dEph0BSrKU3/vFA== =P2KB -----END PGP SIGNATURE----- --=-spHfnjbbIi+e7UZn+wYh--