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=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=unavailable 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 B9C1AC43630 for ; Wed, 25 Sep 2019 14:53:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9B99521E6F for ; Wed, 25 Sep 2019 14:53:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437957AbfIYOxG (ORCPT ); Wed, 25 Sep 2019 10:53:06 -0400 Received: from mx2.suse.de ([195.135.220.15]:57190 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726036AbfIYOxG (ORCPT ); Wed, 25 Sep 2019 10:53:06 -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 47F59AEE1; Wed, 25 Sep 2019 14:53:02 +0000 (UTC) Message-ID: Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters From: Nicolas Saenz Julienne To: Rob Herring Cc: devicetree@vger.kernel.org, Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-wireless , "linux-kernel@vger.kernel.org" , linux-arm-msm , "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , etnaviv@lists.freedesktop.org, dri-devel , xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org, Linux Media Mailing List , linux-pci@vger.kernel.org, Matthias Brugger , Robin Murphy , Florian Fainelli , james.quinlan@broadcom.com, Stefan Wahren , Dan Williams , freedreno Date: Wed, 25 Sep 2019 16:52:59 +0200 In-Reply-To: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-5Mzcra9IsjRjM5vnaomh" User-Agent: Evolution 3.32.4 MIME-Version: 1.0 Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org --=-5Mzcra9IsjRjM5vnaomh Content-Type: multipart/mixed; boundary="=-QzsDiLgE5dpWVAyKk5Wj" --=-QzsDiLgE5dpWVAyKk5Wj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote: > On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne > wrote: > > Hi All, > > this series tries to address one of the issues blocking us from > > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that > > devices not represented in DT which sit behind a PCI bus fail to get th= e > > bus' DMA addressing constraints. > >=20 > > This is due to the fact that of_dma_configure() assumes it's receiving = a > > DT node representing the device being configured, as opposed to the PCI= e > > bridge node we currently pass. This causes the code to directly jump > > into PCI's parent node when checking for 'dma-ranges' and misses > > whatever was set there. > >=20 > > To address this I create a new API in OF - inspired from Robin Murphys > > original proposal[2] - which accepts a bus DT node as it's input in > > order to configure a device's DMA constraints. The changes go deep into > > of/address.c's implementation, as a device being having a DT node > > assumption was pretty strong. > >=20 > > On top of this work, I also cleaned up of_dma_configure() removing its > > redundant arguments and creating an alternative function for the specia= l > > cases > > not applicable to either the above case or the default usage. > >=20 > > IMO the resulting functions are more explicit. They will probably > > surface some hacky usages that can be properly fixed as I show with the > > DT fixes on the Layerscape platform. > >=20 > > This was also tested on a Raspberry Pi 4 with a custom PCIe driver and > > on a Seattle AMD board. >=20 > Humm, I've been working on this issue too. Looks similar though yours > has a lot more churn and there's some other bugs I've found. That's good news, and yes now that I see it, some stuff on my series is ove= rly complicated. Specially around of_translate_*(). On top of that, you removed in of_dma_get_range(): - /* - * At least empty ranges has to be defined for parent node if - * DMA is supported - */ - if (!ranges) - break; Which I assumed was bound to the standard and makes things easier. > Can you test out this branch[1]. I don't have any h/w needing this, > but wrote a unittest and tested with modified QEMU. I reviewed everything, I did find a minor issue, see the patch attached. Also I tested your branch both on an RPi4, with a PCI device that depends o= n these changes and by comparing the OF debugs logs on a Layerscape board whi= ch uses dma-ranges, dma-coherent and IOMMU. All works as expected. Will you send this series for v5.5? Please keep me in the loop, I'll review= and test the final version. Regards, Nicolas --=-QzsDiLgE5dpWVAyKk5Wj Content-Disposition: attachment; filename*0=0001-of-device-do-not-bail-of_dma_configure-when-force_dm.pat; filename*1=ch Content-Type: text/x-patch; name="0001-of-device-do-not-bail-of_dma_configure-when-force_dm.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAyNmQ1MTg1M2MyNWMwNGMyOGRiYzA5MDYxOTUxYTkzYzEwMmRhYmNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIFNhZW56IEp1bGllbm5lIDxuc2FlbnpqdWxpZW5u ZUBzdXNlLmRlPgpEYXRlOiBXZWQsIDI1IFNlcCAyMDE5IDE2OjI2OjU3ICswMjAwClN1YmplY3Q6 IFtQQVRDSF0gb2Y6IGRldmljZTogZG8gbm90IGJhaWwgb2ZfZG1hX2NvbmZpZ3VyZSgpIHdoZW4g Zm9yY2VfZG1hIGlzCiBzZXQKClNvbWUgWGVuIGRldmljZXMgY2FsbCBvZl9kbWFfY29uZmlndXJl KCkgd2l0aG91dCBhbiBhY3R1YWwgRFQgbm9kZSBpbgpvcmRlciBmb3IgaXQgdG8gc2V0IGl0cyAn ZG1hX29wcycuIFRoYXQncyB0aGUgb3JpZ2luYWwgaW50ZW50IG9mCidmb3JjZV9kbWEnLCBob25v ciB0aGF0IGJlaGF2aW91ci4KClNpZ25lZC1vZmYtYnk6IE5pY29sYXMgU2FlbnogSnVsaWVubmUg PG5zYWVuemp1bGllbm5lQHN1c2UuZGU+Ci0tLQogZHJpdmVycy9vZi9kZXZpY2UuYyB8IDIgLS0K IDEgZmlsZSBjaGFuZ2VkLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2Yv ZGV2aWNlLmMgYi9kcml2ZXJzL29mL2RldmljZS5jCmluZGV4IGE0NTI2MWUyMTE0NC4uN2JjMDBm NzI0NjhmIDEwMDY0NAotLS0gYS9kcml2ZXJzL29mL2RldmljZS5jCisrKyBiL2RyaXZlcnMvb2Yv ZGV2aWNlLmMKQEAgLTEwMCw4ICsxMDAsNiBAQCBpbnQgb2ZfZG1hX2NvbmZpZ3VyZShzdHJ1Y3Qg ZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2Vfbm9kZSAqcGFyZW50LCBib29sIGZvcmNlXwogCW5w ID0gZGV2LT5vZl9ub2RlOwogCWlmICghbnApCiAJCW5wID0gcGFyZW50OwotCWlmICghbnApCi0J CXJldHVybiAtRU5PREVWOwogCiAJcmV0ID0gb2ZfZG1hX2dldF9yYW5nZShucCwgJmRtYV9hZGRy LCAmcGFkZHIsICZzaXplKTsKIAlpZiAocmV0IDwgMCkgewotLSAKMi4yMy4wCgo= --=-QzsDiLgE5dpWVAyKk5Wj-- --=-5Mzcra9IsjRjM5vnaomh 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/4FAl2Lf0sACgkQlfZmHno8 x/7mvQf6A++shc7v4vCUvlFLh6kIZ0UPBKuSnxpUpUn+R3BMoS6J5Ce/ma0SOzIJ MRQmawROuL2F6qf0g3ykdpnaSD14TAEB9UnJzLoTkprKRFRhdq4pQjCDGDWIpWSO fW6GnBbCLaTa0r38siU1DvnV3ZXCNnmN+lO5mqEp380R7cLwMj0hrH4mzkNuSUHK uKWLMd/ZZyDk7e2j1qZ2bXg6PRRSfXZfU7Oqtwt6k7JNoPB/HneraMxoO43EyzDA qt4Fxx6cDsZQAPbqJPChpSN4USdi0rN171NlKW3+PRsGfZN4LzUF3MoK2uvReV0n DhW7JoNOzqhh0pk2iPTRov0M+zbYEg== =jmQ8 -----END PGP SIGNATURE----- --=-5Mzcra9IsjRjM5vnaomh-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Saenz Julienne Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters Date: Wed, 25 Sep 2019 16:52:59 +0200 Message-ID: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-5Mzcra9IsjRjM5vnaomh" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Rob Herring Cc: devicetree@vger.kernel.org, Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , linux-wireless , "linux-kernel@vger.kernel.org" , linux-arm-msm , "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , etnaviv@lists.freedesktop.org, dri-devel , xen-devel@lists.xenproject.org, linux-tegra@vger.kernel.org, Linux Media Mailing List , linux-pci@vger.kernel.org, Matthias Brugger , Robin Murphy , Florian Fainelli , james.quinlan@broadcom.comStefan Wahren List-Id: linux-tegra@vger.kernel.org --=-5Mzcra9IsjRjM5vnaomh Content-Type: multipart/mixed; boundary="=-QzsDiLgE5dpWVAyKk5Wj" --=-QzsDiLgE5dpWVAyKk5Wj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote: > On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne > wrote: > > Hi All, > > this series tries to address one of the issues blocking us from > > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that > > devices not represented in DT which sit behind a PCI bus fail to get th= e > > bus' DMA addressing constraints. > >=20 > > This is due to the fact that of_dma_configure() assumes it's receiving = a > > DT node representing the device being configured, as opposed to the PCI= e > > bridge node we currently pass. This causes the code to directly jump > > into PCI's parent node when checking for 'dma-ranges' and misses > > whatever was set there. > >=20 > > To address this I create a new API in OF - inspired from Robin Murphys > > original proposal[2] - which accepts a bus DT node as it's input in > > order to configure a device's DMA constraints. The changes go deep into > > of/address.c's implementation, as a device being having a DT node > > assumption was pretty strong. > >=20 > > On top of this work, I also cleaned up of_dma_configure() removing its > > redundant arguments and creating an alternative function for the specia= l > > cases > > not applicable to either the above case or the default usage. > >=20 > > IMO the resulting functions are more explicit. They will probably > > surface some hacky usages that can be properly fixed as I show with the > > DT fixes on the Layerscape platform. > >=20 > > This was also tested on a Raspberry Pi 4 with a custom PCIe driver and > > on a Seattle AMD board. >=20 > Humm, I've been working on this issue too. Looks similar though yours > has a lot more churn and there's some other bugs I've found. That's good news, and yes now that I see it, some stuff on my series is ove= rly complicated. Specially around of_translate_*(). On top of that, you removed in of_dma_get_range(): - /* - * At least empty ranges has to be defined for parent node if - * DMA is supported - */ - if (!ranges) - break; Which I assumed was bound to the standard and makes things easier. > Can you test out this branch[1]. I don't have any h/w needing this, > but wrote a unittest and tested with modified QEMU. I reviewed everything, I did find a minor issue, see the patch attached. Also I tested your branch both on an RPi4, with a PCI device that depends o= n these changes and by comparing the OF debugs logs on a Layerscape board whi= ch uses dma-ranges, dma-coherent and IOMMU. All works as expected. Will you send this series for v5.5? Please keep me in the loop, I'll review= and test the final version. Regards, Nicolas --=-QzsDiLgE5dpWVAyKk5Wj Content-Disposition: attachment; filename*0=0001-of-device-do-not-bail-of_dma_configure-when-force_dm.pat; filename*1=ch Content-Type: text/x-patch; name="0001-of-device-do-not-bail-of_dma_configure-when-force_dm.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAyNmQ1MTg1M2MyNWMwNGMyOGRiYzA5MDYxOTUxYTkzYzEwMmRhYmNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIFNhZW56IEp1bGllbm5lIDxuc2FlbnpqdWxpZW5u ZUBzdXNlLmRlPgpEYXRlOiBXZWQsIDI1IFNlcCAyMDE5IDE2OjI2OjU3ICswMjAwClN1YmplY3Q6 IFtQQVRDSF0gb2Y6IGRldmljZTogZG8gbm90IGJhaWwgb2ZfZG1hX2NvbmZpZ3VyZSgpIHdoZW4g Zm9yY2VfZG1hIGlzCiBzZXQKClNvbWUgWGVuIGRldmljZXMgY2FsbCBvZl9kbWFfY29uZmlndXJl KCkgd2l0aG91dCBhbiBhY3R1YWwgRFQgbm9kZSBpbgpvcmRlciBmb3IgaXQgdG8gc2V0IGl0cyAn ZG1hX29wcycuIFRoYXQncyB0aGUgb3JpZ2luYWwgaW50ZW50IG9mCidmb3JjZV9kbWEnLCBob25v ciB0aGF0IGJlaGF2aW91ci4KClNpZ25lZC1vZmYtYnk6IE5pY29sYXMgU2FlbnogSnVsaWVubmUg PG5zYWVuemp1bGllbm5lQHN1c2UuZGU+Ci0tLQogZHJpdmVycy9vZi9kZXZpY2UuYyB8IDIgLS0K IDEgZmlsZSBjaGFuZ2VkLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2Yv ZGV2aWNlLmMgYi9kcml2ZXJzL29mL2RldmljZS5jCmluZGV4IGE0NTI2MWUyMTE0NC4uN2JjMDBm NzI0NjhmIDEwMDY0NAotLS0gYS9kcml2ZXJzL29mL2RldmljZS5jCisrKyBiL2RyaXZlcnMvb2Yv ZGV2aWNlLmMKQEAgLTEwMCw4ICsxMDAsNiBAQCBpbnQgb2ZfZG1hX2NvbmZpZ3VyZShzdHJ1Y3Qg ZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2Vfbm9kZSAqcGFyZW50LCBib29sIGZvcmNlXwogCW5w ID0gZGV2LT5vZl9ub2RlOwogCWlmICghbnApCiAJCW5wID0gcGFyZW50OwotCWlmICghbnApCi0J CXJldHVybiAtRU5PREVWOwogCiAJcmV0ID0gb2ZfZG1hX2dldF9yYW5nZShucCwgJmRtYV9hZGRy LCAmcGFkZHIsICZzaXplKTsKIAlpZiAocmV0IDwgMCkgewotLSAKMi4yMy4wCgo= --=-QzsDiLgE5dpWVAyKk5Wj-- --=-5Mzcra9IsjRjM5vnaomh 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/4FAl2Lf0sACgkQlfZmHno8 x/7mvQf6A++shc7v4vCUvlFLh6kIZ0UPBKuSnxpUpUn+R3BMoS6J5Ce/ma0SOzIJ MRQmawROuL2F6qf0g3ykdpnaSD14TAEB9UnJzLoTkprKRFRhdq4pQjCDGDWIpWSO fW6GnBbCLaTa0r38siU1DvnV3ZXCNnmN+lO5mqEp380R7cLwMj0hrH4mzkNuSUHK uKWLMd/ZZyDk7e2j1qZ2bXg6PRRSfXZfU7Oqtwt6k7JNoPB/HneraMxoO43EyzDA qt4Fxx6cDsZQAPbqJPChpSN4USdi0rN171NlKW3+PRsGfZN4LzUF3MoK2uvReV0n DhW7JoNOzqhh0pk2iPTRov0M+zbYEg== =jmQ8 -----END PGP SIGNATURE----- --=-5Mzcra9IsjRjM5vnaomh-- 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=-6.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 962D8C432C2 for ; Wed, 25 Sep 2019 14:53:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 6D9AD21D7E for ; Wed, 25 Sep 2019 14:53:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="cBzOU+O9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6D9AD21D7E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: MIME-Version:References:In-Reply-To:Date:To:From:Subject:Message-ID:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3WfjR8VoEUo5eulCyHGbIRDD+JxnzrAn5TBVd63hwuc=; b=cBzOU+O982FqgrGSIkeDFIs4I F2bPIX5fH142B8TQuWyTTDYGyeEenoEy7d0DUlnBsbmdPK/pxTHAtyRQoP/Iu4wzIHa9mafJhctVA tLrtmafCgIO9TuCRKkk299cJ7dMP5I3NXi+1DRH1MPxVf7sLOGdLSP0U+l+xQXriE8aSiSJVJuzNg 1yhiS53OyDPhWrtPESH+haFOILSVarX9Z7VlpmGJikdyENEEpIcpZzF7Y+OeceJHyvGVXewdynC8O NDmDyDAz5yY9a1kDCK7URKQXQ7853zNKK6DGcV9bT6pJ+UV0tL/IpkHDoip56GYHRGysjnrHIvKiW bHxmxIOdw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1iD8fH-00012a-02; Wed, 25 Sep 2019 14:53:11 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1iD8fC-00011j-JU for linux-arm-kernel@lists.infradead.org; Wed, 25 Sep 2019 14:53:08 +0000 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 47F59AEE1; Wed, 25 Sep 2019 14:53:02 +0000 (UTC) Message-ID: Subject: Re: [PATCH 00/11] of: Fix DMA configuration for non-DT masters From: Nicolas Saenz Julienne To: Rob Herring Date: Wed, 25 Sep 2019 16:52:59 +0200 In-Reply-To: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> User-Agent: Evolution 3.32.4 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190925_075306_940633_3876E6DB X-CRM114-Status: GOOD ( 27.43 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , freedreno , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , Robin Murphy , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: multipart/mixed; boundary="===============5882416185891835697==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============5882416185891835697== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-5Mzcra9IsjRjM5vnaomh" --=-5Mzcra9IsjRjM5vnaomh Content-Type: multipart/mixed; boundary="=-QzsDiLgE5dpWVAyKk5Wj" --=-QzsDiLgE5dpWVAyKk5Wj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote: > On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne > wrote: > > Hi All, > > this series tries to address one of the issues blocking us from > > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that > > devices not represented in DT which sit behind a PCI bus fail to get th= e > > bus' DMA addressing constraints. > >=20 > > This is due to the fact that of_dma_configure() assumes it's receiving = a > > DT node representing the device being configured, as opposed to the PCI= e > > bridge node we currently pass. This causes the code to directly jump > > into PCI's parent node when checking for 'dma-ranges' and misses > > whatever was set there. > >=20 > > To address this I create a new API in OF - inspired from Robin Murphys > > original proposal[2] - which accepts a bus DT node as it's input in > > order to configure a device's DMA constraints. The changes go deep into > > of/address.c's implementation, as a device being having a DT node > > assumption was pretty strong. > >=20 > > On top of this work, I also cleaned up of_dma_configure() removing its > > redundant arguments and creating an alternative function for the specia= l > > cases > > not applicable to either the above case or the default usage. > >=20 > > IMO the resulting functions are more explicit. They will probably > > surface some hacky usages that can be properly fixed as I show with the > > DT fixes on the Layerscape platform. > >=20 > > This was also tested on a Raspberry Pi 4 with a custom PCIe driver and > > on a Seattle AMD board. >=20 > Humm, I've been working on this issue too. Looks similar though yours > has a lot more churn and there's some other bugs I've found. That's good news, and yes now that I see it, some stuff on my series is ove= rly complicated. Specially around of_translate_*(). On top of that, you removed in of_dma_get_range(): - /* - * At least empty ranges has to be defined for parent node if - * DMA is supported - */ - if (!ranges) - break; Which I assumed was bound to the standard and makes things easier. > Can you test out this branch[1]. I don't have any h/w needing this, > but wrote a unittest and tested with modified QEMU. I reviewed everything, I did find a minor issue, see the patch attached. Also I tested your branch both on an RPi4, with a PCI device that depends o= n these changes and by comparing the OF debugs logs on a Layerscape board whi= ch uses dma-ranges, dma-coherent and IOMMU. All works as expected. Will you send this series for v5.5? Please keep me in the loop, I'll review= and test the final version. Regards, Nicolas --=-QzsDiLgE5dpWVAyKk5Wj Content-Disposition: attachment; filename*0=0001-of-device-do-not-bail-of_dma_configure-when-force_dm.pat; filename*1=ch Content-Type: text/x-patch; name="0001-of-device-do-not-bail-of_dma_configure-when-force_dm.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAyNmQ1MTg1M2MyNWMwNGMyOGRiYzA5MDYxOTUxYTkzYzEwMmRhYmNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIFNhZW56IEp1bGllbm5lIDxuc2FlbnpqdWxpZW5u ZUBzdXNlLmRlPgpEYXRlOiBXZWQsIDI1IFNlcCAyMDE5IDE2OjI2OjU3ICswMjAwClN1YmplY3Q6 IFtQQVRDSF0gb2Y6IGRldmljZTogZG8gbm90IGJhaWwgb2ZfZG1hX2NvbmZpZ3VyZSgpIHdoZW4g Zm9yY2VfZG1hIGlzCiBzZXQKClNvbWUgWGVuIGRldmljZXMgY2FsbCBvZl9kbWFfY29uZmlndXJl KCkgd2l0aG91dCBhbiBhY3R1YWwgRFQgbm9kZSBpbgpvcmRlciBmb3IgaXQgdG8gc2V0IGl0cyAn ZG1hX29wcycuIFRoYXQncyB0aGUgb3JpZ2luYWwgaW50ZW50IG9mCidmb3JjZV9kbWEnLCBob25v ciB0aGF0IGJlaGF2aW91ci4KClNpZ25lZC1vZmYtYnk6IE5pY29sYXMgU2FlbnogSnVsaWVubmUg PG5zYWVuemp1bGllbm5lQHN1c2UuZGU+Ci0tLQogZHJpdmVycy9vZi9kZXZpY2UuYyB8IDIgLS0K IDEgZmlsZSBjaGFuZ2VkLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2Yv ZGV2aWNlLmMgYi9kcml2ZXJzL29mL2RldmljZS5jCmluZGV4IGE0NTI2MWUyMTE0NC4uN2JjMDBm NzI0NjhmIDEwMDY0NAotLS0gYS9kcml2ZXJzL29mL2RldmljZS5jCisrKyBiL2RyaXZlcnMvb2Yv ZGV2aWNlLmMKQEAgLTEwMCw4ICsxMDAsNiBAQCBpbnQgb2ZfZG1hX2NvbmZpZ3VyZShzdHJ1Y3Qg ZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2Vfbm9kZSAqcGFyZW50LCBib29sIGZvcmNlXwogCW5w ID0gZGV2LT5vZl9ub2RlOwogCWlmICghbnApCiAJCW5wID0gcGFyZW50OwotCWlmICghbnApCi0J CXJldHVybiAtRU5PREVWOwogCiAJcmV0ID0gb2ZfZG1hX2dldF9yYW5nZShucCwgJmRtYV9hZGRy LCAmcGFkZHIsICZzaXplKTsKIAlpZiAocmV0IDwgMCkgewotLSAKMi4yMy4wCgo= --=-QzsDiLgE5dpWVAyKk5Wj-- --=-5Mzcra9IsjRjM5vnaomh 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/4FAl2Lf0sACgkQlfZmHno8 x/7mvQf6A++shc7v4vCUvlFLh6kIZ0UPBKuSnxpUpUn+R3BMoS6J5Ce/ma0SOzIJ MRQmawROuL2F6qf0g3ykdpnaSD14TAEB9UnJzLoTkprKRFRhdq4pQjCDGDWIpWSO fW6GnBbCLaTa0r38siU1DvnV3ZXCNnmN+lO5mqEp380R7cLwMj0hrH4mzkNuSUHK uKWLMd/ZZyDk7e2j1qZ2bXg6PRRSfXZfU7Oqtwt6k7JNoPB/HneraMxoO43EyzDA qt4Fxx6cDsZQAPbqJPChpSN4USdi0rN171NlKW3+PRsGfZN4LzUF3MoK2uvReV0n DhW7JoNOzqhh0pk2iPTRov0M+zbYEg== =jmQ8 -----END PGP SIGNATURE----- --=-5Mzcra9IsjRjM5vnaomh-- --===============5882416185891835697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============5882416185891835697==-- 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=-6.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 6E8B3C432C2 for ; Wed, 25 Sep 2019 15:11:50 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3FDE121D7B for ; Wed, 25 Sep 2019 15:11:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3FDE121D7B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iD8x9-0004BX-VK; Wed, 25 Sep 2019 15:11:39 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iD8fB-000286-AO for xen-devel@lists.xenproject.org; Wed, 25 Sep 2019 14:53:05 +0000 X-Inumbo-ID: 2ce9a642-dfa4-11e9-bf31-bc764e2007e4 Received: from mx1.suse.de (unknown [195.135.220.15]) by localhost (Halon) with ESMTPS id 2ce9a642-dfa4-11e9-bf31-bc764e2007e4; Wed, 25 Sep 2019 14:53:03 +0000 (UTC) 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 47F59AEE1; Wed, 25 Sep 2019 14:53:02 +0000 (UTC) Message-ID: From: Nicolas Saenz Julienne To: Rob Herring Date: Wed, 25 Sep 2019 16:52:59 +0200 In-Reply-To: References: <20190924181244.7159-1-nsaenzjulienne@suse.de> User-Agent: Evolution 3.32.4 MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Sep 2019 15:11:38 +0000 Subject: Re: [Xen-devel] [PATCH 00/11] of: Fix DMA configuration for non-DT masters X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Matthias Brugger , linux-arm-msm , freedreno , linux-wireless , "linux-kernel@vger.kernel.org" , dri-devel , etnaviv@lists.freedesktop.org, linux-tegra@vger.kernel.org, Florian Fainelli , Stefan Wahren , james.quinlan@broadcom.com, linux-pci@vger.kernel.org, "open list:DMA GENERIC OFFLOAD ENGINE SUBSYSTEM" , xen-devel@lists.xenproject.org, Dan Williams , Robin Murphy , Frank Rowand , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , Linux Media Mailing List Content-Type: multipart/mixed; boundary="===============9060129792173961816==" Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" --===============9060129792173961816== Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-5Mzcra9IsjRjM5vnaomh" --=-5Mzcra9IsjRjM5vnaomh Content-Type: multipart/mixed; boundary="=-QzsDiLgE5dpWVAyKk5Wj" --=-QzsDiLgE5dpWVAyKk5Wj Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2019-09-24 at 16:59 -0500, Rob Herring wrote: > On Tue, Sep 24, 2019 at 1:12 PM Nicolas Saenz Julienne > wrote: > > Hi All, > > this series tries to address one of the issues blocking us from > > upstreaming Broadcom's STB PCIe controller[1]. Namely, the fact that > > devices not represented in DT which sit behind a PCI bus fail to get th= e > > bus' DMA addressing constraints. > >=20 > > This is due to the fact that of_dma_configure() assumes it's receiving = a > > DT node representing the device being configured, as opposed to the PCI= e > > bridge node we currently pass. This causes the code to directly jump > > into PCI's parent node when checking for 'dma-ranges' and misses > > whatever was set there. > >=20 > > To address this I create a new API in OF - inspired from Robin Murphys > > original proposal[2] - which accepts a bus DT node as it's input in > > order to configure a device's DMA constraints. The changes go deep into > > of/address.c's implementation, as a device being having a DT node > > assumption was pretty strong. > >=20 > > On top of this work, I also cleaned up of_dma_configure() removing its > > redundant arguments and creating an alternative function for the specia= l > > cases > > not applicable to either the above case or the default usage. > >=20 > > IMO the resulting functions are more explicit. They will probably > > surface some hacky usages that can be properly fixed as I show with the > > DT fixes on the Layerscape platform. > >=20 > > This was also tested on a Raspberry Pi 4 with a custom PCIe driver and > > on a Seattle AMD board. >=20 > Humm, I've been working on this issue too. Looks similar though yours > has a lot more churn and there's some other bugs I've found. That's good news, and yes now that I see it, some stuff on my series is ove= rly complicated. Specially around of_translate_*(). On top of that, you removed in of_dma_get_range(): - /* - * At least empty ranges has to be defined for parent node if - * DMA is supported - */ - if (!ranges) - break; Which I assumed was bound to the standard and makes things easier. > Can you test out this branch[1]. I don't have any h/w needing this, > but wrote a unittest and tested with modified QEMU. I reviewed everything, I did find a minor issue, see the patch attached. Also I tested your branch both on an RPi4, with a PCI device that depends o= n these changes and by comparing the OF debugs logs on a Layerscape board whi= ch uses dma-ranges, dma-coherent and IOMMU. All works as expected. Will you send this series for v5.5? Please keep me in the loop, I'll review= and test the final version. Regards, Nicolas --=-QzsDiLgE5dpWVAyKk5Wj Content-Disposition: attachment; filename*0=0001-of-device-do-not-bail-of_dma_configure-when-force_dm.pat; filename*1=ch Content-Type: text/x-patch; name="0001-of-device-do-not-bail-of_dma_configure-when-force_dm.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAyNmQ1MTg1M2MyNWMwNGMyOGRiYzA5MDYxOTUxYTkzYzEwMmRhYmNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBOaWNvbGFzIFNhZW56IEp1bGllbm5lIDxuc2FlbnpqdWxpZW5u ZUBzdXNlLmRlPgpEYXRlOiBXZWQsIDI1IFNlcCAyMDE5IDE2OjI2OjU3ICswMjAwClN1YmplY3Q6 IFtQQVRDSF0gb2Y6IGRldmljZTogZG8gbm90IGJhaWwgb2ZfZG1hX2NvbmZpZ3VyZSgpIHdoZW4g Zm9yY2VfZG1hIGlzCiBzZXQKClNvbWUgWGVuIGRldmljZXMgY2FsbCBvZl9kbWFfY29uZmlndXJl KCkgd2l0aG91dCBhbiBhY3R1YWwgRFQgbm9kZSBpbgpvcmRlciBmb3IgaXQgdG8gc2V0IGl0cyAn ZG1hX29wcycuIFRoYXQncyB0aGUgb3JpZ2luYWwgaW50ZW50IG9mCidmb3JjZV9kbWEnLCBob25v ciB0aGF0IGJlaGF2aW91ci4KClNpZ25lZC1vZmYtYnk6IE5pY29sYXMgU2FlbnogSnVsaWVubmUg PG5zYWVuemp1bGllbm5lQHN1c2UuZGU+Ci0tLQogZHJpdmVycy9vZi9kZXZpY2UuYyB8IDIgLS0K IDEgZmlsZSBjaGFuZ2VkLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2RyaXZlcnMvb2Yv ZGV2aWNlLmMgYi9kcml2ZXJzL29mL2RldmljZS5jCmluZGV4IGE0NTI2MWUyMTE0NC4uN2JjMDBm NzI0NjhmIDEwMDY0NAotLS0gYS9kcml2ZXJzL29mL2RldmljZS5jCisrKyBiL2RyaXZlcnMvb2Yv ZGV2aWNlLmMKQEAgLTEwMCw4ICsxMDAsNiBAQCBpbnQgb2ZfZG1hX2NvbmZpZ3VyZShzdHJ1Y3Qg ZGV2aWNlICpkZXYsIHN0cnVjdCBkZXZpY2Vfbm9kZSAqcGFyZW50LCBib29sIGZvcmNlXwogCW5w ID0gZGV2LT5vZl9ub2RlOwogCWlmICghbnApCiAJCW5wID0gcGFyZW50OwotCWlmICghbnApCi0J CXJldHVybiAtRU5PREVWOwogCiAJcmV0ID0gb2ZfZG1hX2dldF9yYW5nZShucCwgJmRtYV9hZGRy LCAmcGFkZHIsICZzaXplKTsKIAlpZiAocmV0IDwgMCkgewotLSAKMi4yMy4wCgo= --=-QzsDiLgE5dpWVAyKk5Wj-- --=-5Mzcra9IsjRjM5vnaomh 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/4FAl2Lf0sACgkQlfZmHno8 x/7mvQf6A++shc7v4vCUvlFLh6kIZ0UPBKuSnxpUpUn+R3BMoS6J5Ce/ma0SOzIJ MRQmawROuL2F6qf0g3ykdpnaSD14TAEB9UnJzLoTkprKRFRhdq4pQjCDGDWIpWSO fW6GnBbCLaTa0r38siU1DvnV3ZXCNnmN+lO5mqEp380R7cLwMj0hrH4mzkNuSUHK uKWLMd/ZZyDk7e2j1qZ2bXg6PRRSfXZfU7Oqtwt6k7JNoPB/HneraMxoO43EyzDA qt4Fxx6cDsZQAPbqJPChpSN4USdi0rN171NlKW3+PRsGfZN4LzUF3MoK2uvReV0n DhW7JoNOzqhh0pk2iPTRov0M+zbYEg== =jmQ8 -----END PGP SIGNATURE----- --=-5Mzcra9IsjRjM5vnaomh-- --===============9060129792173961816== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVucHJvamVjdC5vcmcKaHR0cHM6Ly9saXN0 cy54ZW5wcm9qZWN0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3hlbi1kZXZlbA== --===============9060129792173961816==--