From owner-freebsd-arm@FreeBSD.ORG Thu Jan 31 19:24:31 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8A3B5E2A for ; Thu, 31 Jan 2013 19:24:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2DAF2CB3 for ; Thu, 31 Jan 2013 19:24:31 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0VJORrN089446 for ; Thu, 31 Jan 2013 21:24:27 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0VJORrN089446 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0VJORAH089445 for arm@freebsd.org; Thu, 31 Jan 2013 21:24:27 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 31 Jan 2013 21:24:27 +0200 From: Konstantin Belousov To: arm@freebsd.org Subject: bud_dmamap_load_buffer() Message-ID: <20130131192426.GL2522@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z4nOpqXAzw5l7GJN" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:24:31 -0000 --z4nOpqXAzw5l7GJN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I noted that arm/busdma_machdep.c uses essentially inlined pmap_kextract() to get the physical address from the kernel address. I consulted with gonzo, who said that he does not see a reason for inlining the code. My theory is that before r240983, pmap_kextract() locked the pmap, which caused unneeded and probably wrong locking in the busdma load path. Since this issue is fixed, I see no reason for directly walking the page tables. Could somebody please review and test the patch ? v6 busdma already uses pmap_kextract(). Do not remove me from Cc:. diff --git a/sys/arm/arm/busdma_machdep.c b/sys/arm/arm/busdma_machdep.c index 42566e8..8f49300 100644 --- a/sys/arm/arm/busdma_machdep.c +++ b/sys/arm/arm/busdma_machdep.c @@ -849,9 +849,6 @@ bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_segm= ent_t *segs, vm_offset_t vaddr =3D (vm_offset_t)buf; int seg; int error =3D 0; - pd_entry_t *pde; - pt_entry_t pte; - pt_entry_t *ptep; =20 lastaddr =3D *lastaddrp; bmask =3D ~(dmat->boundary - 1); @@ -873,29 +870,7 @@ bus_dmamap_load_buffer(bus_dma_tag_t dmat, bus_dma_seg= ment_t *segs, * XXX in user address space. */ if (__predict_true(pmap =3D=3D pmap_kernel())) { - if (pmap_get_pde_pte(pmap, vaddr, &pde, &ptep) =3D=3D FALSE) - return (EFAULT); - - if (__predict_false(pmap_pde_section(pde))) { - if (*pde & L1_S_SUPERSEC) - curaddr =3D (*pde & L1_SUP_FRAME) | - (vaddr & L1_SUP_OFFSET); - else - curaddr =3D (*pde & L1_S_FRAME) | - (vaddr & L1_S_OFFSET); - } else { - pte =3D *ptep; - KASSERT((pte & L2_TYPE_MASK) !=3D L2_TYPE_INV, - ("INV type")); - if (__predict_false((pte & L2_TYPE_MASK) - =3D=3D L2_TYPE_L)) { - curaddr =3D (pte & L2_L_FRAME) | - (vaddr & L2_L_OFFSET); - } else { - curaddr =3D (pte & L2_S_FRAME) | - (vaddr & L2_S_OFFSET); - } - } + curaddr =3D pmap_kextract(vaddr); } else { curaddr =3D pmap_extract(pmap, vaddr); map->flags &=3D ~DMAMAP_COHERENT; --z4nOpqXAzw5l7GJN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRCsTqAAoJEJDCuSvBvK1BTzwQAIPcEMlx85tOGNMkVWIOdEvn nJb2ZJJQ0OP71A/g7K2Clp5aygAnaC+qdGot/dgTf+g84oywwJkwR961esJYDbb0 pBad/klFPlsZBVv4SC8kzBe4+h16u+jXREmGQeoPi3yOuDx3VMm9twV2awjRQTJg GeMO5tsvyJCBKmK4hapxTXTp18UKfPYMyyvblTXGw+wXUYaXWiUrbUC4kZofxA6z 1bwYKcpmNXD6XQ/Lw3zX1/n0R1ku62jvtKzSUbY8nne7lwmRgCNcGRZYOqZq8Tu7 LPc3F70S7cYKHhDfSHFpH7QC1L/7ztflhczYLxCgRLG52LeBX3NhT9HACMZQn50U /MM9Qd097NqC7JNJde/Dwj2nKyHZjieIFOHwGTPxDzV1fnVpIk8QteTk1j+JmU5Q VB/YXe0mul7bE0PDb39F/pFVB0CU9xV/QmQgsQ9YMA7Fc0WBm5Za7TL+u+d3k9O6 yVoNxEbP1gp7z+QQLAk4TxTb8A8ZGYcNkm9+AuDJVOqO9MmAD0Ny6JIi1C89divE l0HI4b2ZXHRmL+ZTHuXn++Dx1lHm676vHU9Tc8IMUughxzioQjSqeoaLoSVmPcHt LCq1GGdqZpl2uTD2D48rnJL/zI3cpigZsHQTlnfXyCIRrl6MR6lOSI49aDcczgE6 qF2WLIXeraiuBEo4TFMs =eoIV -----END PGP SIGNATURE----- --z4nOpqXAzw5l7GJN--