From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 05:24:53 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69117BC0; Mon, 13 Oct 2014 05:24:53 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23DA2D81; Mon, 13 Oct 2014 05:24:53 +0000 (UTC) Received: by mail-oi0-f51.google.com with SMTP id h136so12050714oig.38 for ; Sun, 12 Oct 2014 22:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ie0enbV1ysSU/HpnrfpfRd5Y+nDGoR47eliYz6/mQ7E=; b=pAt8lk20HOrIQYCWbs4tVOgTYG6m9C09ObmX5Skaglox9DV2DccJh1MUOZU/hrs/tA MIdWjYuJCbT9H5gp2AQhR3AlryjPWOt28Oi+v6SG1hFHoZi9CVpH0HxrWtDwKOgOYOlm dfM9UWO6s60xrGDfm/pkrHmz8nBbUW9Su0fDCLYp+wgSIwEXkHlOfz1Nt+2HQ7ckvyw2 ypCegCHmS5KEqPt5WnifhJ6nan1M4+iwvoxx6YbGLCoExO9zxXs5ju3jSHe2Fr9qr/pI Uy7kRWb3Imd5NCm1KwhbcRDDGcanYbSoS7j1sbXaJzTVvPiilMH7qs/XcE7F5DloRqjf 0s7w== MIME-Version: 1.0 X-Received: by 10.202.196.214 with SMTP id u205mr5847391oif.48.1413177892130; Sun, 12 Oct 2014 22:24:52 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Sun, 12 Oct 2014 22:24:52 -0700 (PDT) In-Reply-To: <20141006171521.GD26076@kib.kiev.ua> References: <20141006171521.GD26076@kib.kiev.ua> Date: Mon, 13 Oct 2014 02:24:52 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 05:24:53 -0000 Hi again! I'm in the middle of implementing DMA support for the Allwinner driver, and I was surprised to see that BSD doesn't have a simple DMA API as Linux does. Namely, I didn't see anything like the scatterlists used in Linux. The host found in Allwinner SoCs uses a DMA controller which works with a linked list of descriptors, each having info on a data buffer. In the Linux driver they allocate a coherent DMA buffer using dma_alloc_coherent to get both the virtual and bus addresses of the descriptor list. When it's time to do a DMA transfer, the Linux driver allocates a scatterlist with each entry being a buffer corresponding to a descriptor; it then loops through the descriptor list setting the "buffer pointer" field of each one to the bus address of the corresponding scatterlist entry, and the "next descriptor" to the bus address of the following descriptor. It's pretty neat, though it's worth mentioning the scatterlist that the MMC request handler maps already contains the virtual addresses of the requested buffers. Do we have anything like that on BSD? If not, what would be a simple algorithm to make this work? Again, thanks a lot! From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 12:50:47 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 164ADA07 for ; Mon, 13 Oct 2014 12:50:47 +0000 (UTC) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDEC3E85 for ; Mon, 13 Oct 2014 12:50:46 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id n8so4406224qaq.28 for ; Mon, 13 Oct 2014 05:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dCCOmxupvpW0whK5n+YHGnX1vZqRdqYq3d/g2VxoCJU=; b=QTKVfhJDmxCbcgfLSIMdPtUI0h36RZ7VRyF0Ld4+wgM/5qxyVHHi4oFN8fR2Mwjmm1 m47S+3uF+NEylFGAG7sLdO60H46zHgPXtGoDR+S8HF9TbPK0WY7OaMo99kgjYrpXWFGP 9LmLvuQh5RI5otxyXz7ptiwsX29K8Uvw14Yn1I4CsquJ5FUNIDkMEEuIqjN3JquJL3K6 EVIPgybIv/DoNpNo8u0jP4CbmcnUbGuS/cC05PdNtlvrznmXLSoM03xtbdg++CuqFKql GUNKLM+ecAkqIIWOBteuSzhP9PfenQYaN6hBKD7K+7mG5Hw12X61MXZIpelGG0snd51/ jeOw== MIME-Version: 1.0 X-Received: by 10.224.136.72 with SMTP id q8mr41306485qat.31.1413204645133; Mon, 13 Oct 2014 05:50:45 -0700 (PDT) Received: by 10.140.27.234 with HTTP; Mon, 13 Oct 2014 05:50:45 -0700 (PDT) Date: Mon, 13 Oct 2014 09:50:45 -0300 Message-ID: Subject: How the FreeBSD developers solve problems that are not resolved by Assembly? From: =?UTF-8?Q?fran=C3=A7ai_s?= To: freebsd-drivers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 12:50:47 -0000 I think that the only case where you have to resort to writing binary code manually is when the assembler cannot output the desired code for some reason. If I recall correctly, there is only one such case in the HelenOS sources: http://trac.helenos.org/browser/mainline/kernel/arch/mips32/include/debug.h?rev=mainline%2C1446.3.1 Here they manually encode the opcodes of five special debugging instructions for the MSIM MIPS simulator (these instructions are not part of the standard MIPS ISA, thus the assembler does not know them). But the developers of FreeBSD not write binary code manually. How the FreeBSD developers solve problems that are not resolved by Assembly? From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 14:21:42 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9327EC1B; Mon, 13 Oct 2014 14:21:42 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F01A0B13; Mon, 13 Oct 2014 14:21:41 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9DELWlq051238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 17:21:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9DELWlq051238 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9DELWYi051237; Mon, 13 Oct 2014 17:21:32 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 13 Oct 2014 17:21:32 +0300 From: Konstantin Belousov To: Martin Galvan Subject: Re: A few questions about SD/MMC drivers Message-ID: <20141013142132.GN2153@kib.kiev.ua> References: <20141006171521.GD26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:21:42 -0000 On Mon, Oct 13, 2014 at 02:24:52AM -0300, Martin Galvan wrote: > Hi again! I'm in the middle of implementing DMA support for the > Allwinner driver, and I was surprised to see that BSD doesn't have a > simple DMA API as Linux does. Namely, I didn't see anything like the > scatterlists used in Linux. > > The host found in Allwinner SoCs uses a DMA controller which works > with a linked list of descriptors, each having info on a data buffer. > In the Linux driver they allocate a coherent DMA buffer using > dma_alloc_coherent to get both the virtual and bus addresses of the > descriptor list. When it's time to do a DMA transfer, the Linux driver > allocates a scatterlist with each entry being a buffer corresponding > to a descriptor; it then loops through the descriptor list setting the > "buffer pointer" field of each one to the bus address of the > corresponding scatterlist entry, and the "next descriptor" to the bus > address of the following descriptor. It's pretty neat, though it's > worth mentioning the scatterlist that the MMC request handler maps > already contains the virtual addresses of the requested buffers. > > Do we have anything like that on BSD? If not, what would be a simple > algorithm to make this work? I am not sure about the scope of your question. Are you aware of busdma(9) ? This is the KPI to use for DMA programming on *BSD, and it is typically enough for most hardware. If you do know about busdma(9) and do not consider it not suitable for the task, this is completely different situation, and you should describe why. From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 14:57:35 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 162535C7 for ; Mon, 13 Oct 2014 14:57:35 +0000 (UTC) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D5E07E4C for ; Mon, 13 Oct 2014 14:57:34 +0000 (UTC) Received: by mail-pd0-f170.google.com with SMTP id p10so5777108pdj.15 for ; Mon, 13 Oct 2014 07:57:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hThUuOmJBfqCnnFUFdGJ8k1qBQERv+rOtd6RBfsZdvE=; b=WM+npBp6FUZgUheZOa2P1HcBMatDngxksjp8cMWzhqpouAnmG5qt4GgBX/7sxpdLKM PxylGhXOVeEj2G7nnrTcYSwpUbxkn3lN5utfkTnlpz4kGMaNV+K1DhaR+5ipuZjSD9fG wel/kVNsEDBCUznlhZjyNAOZ/F4gdaoeP0KZUELHp/oDHYH8yk0n4S2x1QnxC9vMzfr/ E2wncuuOoXgIJg5vjMH+03bSOt3ZzXUc5U1KovLfZQHZ+yLfY+levbyneA2LeWmLbycV FKhT3t8Epbh8hUTAQevpAAXyT1Sdnvl7dl1wdd+JLV8g4XuQxQqxxTczEpbjUXGip/Qr wxKw== X-Gm-Message-State: ALoCoQmw0cn2dqReLR6fJhby2xX2K5G9Fv7XtrTvaH43McG0uG8aTETngwhgCyDlLia1GOEVs3LO X-Received: by 10.70.130.136 with SMTP id oe8mr24063394pdb.18.1413212248404; Mon, 13 Oct 2014 07:57:28 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id z13sm11417281pbt.74.2014.10.13.07.57.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 07:57:27 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A few questions about SD/MMC drivers From: Warner Losh In-Reply-To: Date: Mon, 13 Oct 2014 08:57:25 -0600 Message-Id: <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> References: <20141006171521.GD26076@kib.kiev.ua> To: Martin Galvan X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:57:35 -0000 --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: > Hi again! I'm in the middle of implementing DMA support for the > Allwinner driver, and I was surprised to see that BSD doesn't have a > simple DMA API as Linux does. Namely, I didn't see anything like the > scatterlists used in Linux. see busdma(8) for all your DMA needs. It also takes care of situations where bounce buffers are needed, returning properly aligned memory, etc. > The host found in Allwinner SoCs uses a DMA controller which works > with a linked list of descriptors, each having info on a data buffer. > In the Linux driver they allocate a coherent DMA buffer using > dma_alloc_coherent to get both the virtual and bus addresses of the > descriptor list. When it's time to do a DMA transfer, the Linux driver > allocates a scatterlist with each entry being a buffer corresponding > to a descriptor; it then loops through the descriptor list setting the > "buffer pointer" field of each one to the bus address of the > corresponding scatterlist entry, and the "next descriptor" to the bus > address of the following descriptor. It's pretty neat, though it's > worth mentioning the scatterlist that the MMC request handler maps > already contains the virtual addresses of the requested buffers. > > Do we have anything like that on BSD? If not, what would be a simple > algorithm to make this work? Pretty much all of that is covered in busdma(8). The mechanics are a bit different than Linux, sure, but all that functionality is there. Warner --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUO+hVAAoJEGwc0Sh9sBEAxK8QAKrCbArDptS8Zd70zY3wah/L mmii/TgD2aOE/lcB1weJB57lK/2uyRD9EKUOXI4v/TN13mPcUQ9Fo8uaSHSxY8wg NVjiaCmvKHHwB9eQG12SbGnXbcc/ZwY5s8IU58wEC662OEkXShXyUfIOxc+hl1GJ wtIzjS1GQ33WfsgCjhYYMzOIgD04thAhomdrowzo+deWHD7QtOjsiPqn12+OhJdG QDjcSy1+0Z1TA4KtB7hvZR5uDBaSlksGabYzPfPY96yZnfK4ybJSkGRMmKLWpT69 NEgSJ19Fju8egG5tF04Oj2JMV7Retwff5nhA84YFaL0nswY1VxGsT9CdEmyAZq9N 1+l4cMxI01YS2fZRkYdFCzWYO5J42vMqPXoI7+iNfe2QUPIT5fp8XLJdkoyE8Jpo fLg9tGrI+yH8qQq5I31FHG//htSibgG9uUiX57UL6PbVixHANhmkiA3l77/1CpnD 896fs/Den3o1lUSk/eQEa4sJ9ioiyXuOhvykfU2Obpl7IoQ6KwFgLvBOmjgXdNs/ OMXre0F/w7RRFfZ0z8tfEbl7A1gEIox6+oQyTNUP62xit2hrrdizarqy7hPDHdye DGWmgcjLbMGhu3mmOyralyCguJifm+Tuvpr8c6EIFllQrjWcxvP41qalKB+hoM2p xJDJC03VUTUM01kD5GSl =dF3R -----END PGP SIGNATURE----- --Apple-Mail=_5C375B95-34D5-468C-8AAB-B190D7984D7E-- From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 14:59:55 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B087D68B for ; Mon, 13 Oct 2014 14:59:55 +0000 (UTC) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C776E68 for ; Mon, 13 Oct 2014 14:59:55 +0000 (UTC) Received: by mail-pa0-f47.google.com with SMTP id rd3so6020318pab.34 for ; Mon, 13 Oct 2014 07:59:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WuIOjPD+GrQqdRKFr6T4VoP/e6oTuCRewODZY4oGECQ=; b=GHNOjj6wG2Iw2r34nnmjGiGNvkBzFYr9Ys5fkG5IDdVGLq4wlweX45/4Iz8EnXXd5T ADu/1Xyc30lm8Gpidg+7Ordh1r1gBQHXHy2Fn2YbQnFj0v0NYSVne4IruyUPQNebAeAM mIM11CNpEZ/GY7t1u3hlLwMKtGf5LCy2Wi5TLyRibhfZdV54pj3o71vlzdgwN8cPds9V +NzEpeoP8t7bHJPpscb1cTBtYTzws0Ey/2/qSfmVKuBxfnmJpWEvXzfFmYGLT3TjHb8E Ms6BYx7Z3PxcFAmVjyVGt0gIhsNUbDPNWlG5ow8pYtBxTH2+7jwCDFHgZ02IOk9yk7gm qncQ== X-Gm-Message-State: ALoCoQmWmJrFwP8PZk2pPIRxPlAZ4adAaR9awU7ojcy6zYX+nbMDxz/ZTwk82k2iC88gDXL58c4c X-Received: by 10.70.98.132 with SMTP id ei4mr23910102pdb.102.1413212080752; Mon, 13 Oct 2014 07:54:40 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id xf1sm9134491pbb.18.2014.10.13.07.54.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 07:54:40 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_85784895-D37F-4028-B498-FF41133E5A5D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: How the FreeBSD developers solve problems that are not resolved by Assembly? From: Warner Losh In-Reply-To: Date: Mon, 13 Oct 2014 08:54:37 -0600 Message-Id: References: To: =?iso-8859-1?Q?fran=E7ai_s?= X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-drivers@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 14:59:55 -0000 --Apple-Mail=_85784895-D37F-4028-B498-FF41133E5A5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 13, 2014, at 6:50 AM, fran=E7ai s wrote: > I think that the only case where you have to resort to writing binary = code > manually > is when the assembler cannot output the desired code for some reason. > If I recall correctly, there is only one such case in the HelenOS > sources: >=20 > = http://trac.helenos.org/browser/mainline/kernel/arch/mips32/include/debug.= h?rev=3Dmainline%2C1446.3.1 >=20 > Here they manually encode the opcodes of five special debugging > instructions for the MSIM MIPS simulator (these instructions are not > part of the standard MIPS ISA, thus the assembler does not know them). >=20 > But the developers of FreeBSD not write binary code manually. >=20 > How the FreeBSD developers solve problems that are not resolved by = Assembly? More or less the same way. We either create a macro expands to something = like ".word =93 or sometimes the .word is just hard coded = inline when there=92s only going to be one of them. Sometimes we expose = them both in assembly and in C code, in which case what we do varies a = bit to accommodate the different language=92s syntax. It is rare, but = has happened, that we only expose it to C code. Generally, though, we try to add support for the opcodes to gas so that = we get the constraint testing it does (making sure the opcode is = supported at the level you are compiling, making sure it isn=92t in a = delay slot or violating some other precondition for its use). Warner --Apple-Mail=_85784895-D37F-4028-B498-FF41133E5A5D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUO+etAAoJEGwc0Sh9sBEA5/sQAKiV+3YkNVc3qxPKoFo6RqBC KEd6f38YKBTA4DrqwZ1AsU7Y8/U66lsyYKFXkWvmLhE+eqV0pvquXBQ3+AN+eDRN Rjsb4kMKgkp5x3FqA6lW+yS9Z+Z8UucbBXfbv4TGjY8qZ1jW/Xx8L08sAmCXtde0 bfpVqlipR7hlfXtSycVtqDB4Si92RdclRPqmH6AFn5/yP6ZbQ1SR0cwzMn/mEupc Hsxe8TC1cepPI5brnRNkr55jZJsbi51y/+AFD0GZN80WmgJRAkJikd8pyc5hunTB z4TEI8/bYHRQ0uRmS1ElBLPo94xwSaxsdkgdqdVRQbh831c09oxQwU+Ayc1MkEqH UHXNRocjzDnnM0dk/xfeBzNCpk3c4slxZgQytNOW/rgPDnCNL7LuZh5Yz/rKARU9 mupbtSCVpO4scAG4tJHoV0NpMo6PUo6qZvnbm8Q0Q9jEm9T9L2ytfGRojxG+vOdX 8KEEeP4zf7butECHH+aawpi0TMTwB6wBB619hqdeh8RDjcQDYc8fY+UxWXJMjCO8 dWFELzwzjZr9KEdzz7BfNk7yxJg2xPSYUzvdzWt5l9wSediC9kFtrdrna68EO2e3 LhQaHqxXzzVx0viur2K8yM47ojwXBdMoFLHSHNtR5qvYukbn0nT0BKlGwakMwyK1 ncTDcj2O5w2Y5aHFPKpe =C24h -----END PGP SIGNATURE----- --Apple-Mail=_85784895-D37F-4028-B498-FF41133E5A5D-- From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 23:25:36 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 96040593; Mon, 13 Oct 2014 23:25:36 +0000 (UTC) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5576EFD6; Mon, 13 Oct 2014 23:25:36 +0000 (UTC) Received: by mail-oi0-f49.google.com with SMTP id a3so14424594oib.8 for ; Mon, 13 Oct 2014 16:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0R+2P5F54HpR/to7EogwN75vk1D5W2Gquxuanq4K+XE=; b=lSHl6J9vyDiASkeMHfKi4tibdwQBu01LniS40mzT72/nrB5LAOFG4Ho1bAO0geiuCn rDK/1cwGe2qEHzppktXIM6RXmkPoeVMX46GosBQxNmHpECYHP4A0M5hlDMYM3f/Rir8c POTEJKg/pqWubaibxSv68RMcmoTcmvDvtBJkRrfzBXxz0Zdu/r42eF3n67Eo9K8BvFgb 859Bce3OSG+c2F987FVUkNVv0XpD7+3kR6XHMRsiUR1rypBeLsF6fy0xHGN4Nmap4NU5 aNGG/JKxJLapIfvdL0XrOjYGVavrAynVamKBvzzDcnyiByQAUzglnyapkJYN6fo8gvBn GTjA== MIME-Version: 1.0 X-Received: by 10.202.194.67 with SMTP id s64mr1308404oif.22.1413242735697; Mon, 13 Oct 2014 16:25:35 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Mon, 13 Oct 2014 16:25:35 -0700 (PDT) In-Reply-To: <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> Date: Mon, 13 Oct 2014 20:25:35 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 23:25:36 -0000 2014-10-13 11:57 GMT-03:00 Warner Losh : > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: >> The host found in Allwinner SoCs uses a DMA controller which works >> with a linked list of descriptors, each having info on a data buffer. >> In the Linux driver they allocate a coherent DMA buffer using >> dma_alloc_coherent to get both the virtual and bus addresses of the >> descriptor list. When it's time to do a DMA transfer, the Linux driver >> allocates a scatterlist with each entry being a buffer corresponding >> to a descriptor; it then loops through the descriptor list setting the >> "buffer pointer" field of each one to the bus address of the >> corresponding scatterlist entry, and the "next descriptor" to the bus >> address of the following descriptor. It's pretty neat, though it's >> worth mentioning the scatterlist that the MMC request handler maps >> already contains the virtual addresses of the requested buffers. >> >> Do we have anything like that on BSD? If not, what would be a simple >> algorithm to make this work? > > Pretty much all of that is covered in busdma(8). The mechanics are a bit > different than Linux, sure, but all that functionality is there. Actually, other than being able to alloc DMA buffers and get their bus addresses I didn't see anything like the Linux scatterlists. The main problem here is that the Linux mmc_data struct comes with an already-filled scatterlist. In that case, all I have to do is build the descriptor chain with the buffer addresses from the scatterlist entries. The only thing that's similar to that in the BSD API is mbuf_sg, which is used for network stuff. I didn't see anything that could allow me to build a descriptor chain-- all I saw was that the BSD mmc_data type has a buffer instead of a scatterlist. I'm thinking of telling the DMA controller to work with a single descriptor whose buffer is the one that comes inside mmc_data, but I'm not sure if this would be right. Again thanks a lot for your answers. From owner-freebsd-drivers@FreeBSD.ORG Mon Oct 13 23:41:23 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46721A2E; Mon, 13 Oct 2014 23:41:23 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1826F325; Mon, 13 Oct 2014 23:41:22 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XdpEu-0008oE-OR; Mon, 13 Oct 2014 23:41:20 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9DNfJVK045407; Mon, 13 Oct 2014 17:41:19 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18fkrUclnmMr+S3aLX8nn1H X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: A few questions about SD/MMC drivers From: Ian Lepore To: Martin Galvan In-Reply-To: References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 13 Oct 2014 17:41:18 -0600 Message-ID: <1413243678.12052.376.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2014 23:41:23 -0000 On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: > 2014-10-13 11:57 GMT-03:00 Warner Losh : > > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: > >> The host found in Allwinner SoCs uses a DMA controller which works > >> with a linked list of descriptors, each having info on a data buffer. > >> In the Linux driver they allocate a coherent DMA buffer using > >> dma_alloc_coherent to get both the virtual and bus addresses of the > >> descriptor list. When it's time to do a DMA transfer, the Linux driver > >> allocates a scatterlist with each entry being a buffer corresponding > >> to a descriptor; it then loops through the descriptor list setting the > >> "buffer pointer" field of each one to the bus address of the > >> corresponding scatterlist entry, and the "next descriptor" to the bus > >> address of the following descriptor. It's pretty neat, though it's > >> worth mentioning the scatterlist that the MMC request handler maps > >> already contains the virtual addresses of the requested buffers. > >> > >> Do we have anything like that on BSD? If not, what would be a simple > >> algorithm to make this work? > > > > Pretty much all of that is covered in busdma(8). The mechanics are a bit > > different than Linux, sure, but all that functionality is there. > > Actually, other than being able to alloc DMA buffers and get their bus > addresses I didn't see anything like the Linux scatterlists. > > The main problem here is that the Linux mmc_data struct comes with an > already-filled scatterlist. In that case, all I have to do is build > the descriptor chain with the buffer addresses from the scatterlist > entries. The only thing that's similar to that in the BSD API is > mbuf_sg, which is used for network stuff. I didn't see anything that > could allow me to build a descriptor chain-- all I saw was that the > BSD mmc_data type has a buffer instead of a scatterlist. > > I'm thinking of telling the DMA controller to work with a single > descriptor whose buffer is the one that comes inside mmc_data, but I'm > not sure if this would be right. > > Again thanks a lot for your answers. When you map the buffer with bus_dmamap_load() your callback function is passed an array of bus_dma_segment structures, each element of the array is the physical address and size of a contiguous physical segment that makes up part of the overall buffer. You are g'teed not to get more segments than the limit specified in the dma tag used for the map (but that just means the map function fails if there are too many segments, not that some sort of automatic copy/consolidate is done for you). In general you won't have a problem if you handle (512 * MAX_DATA + PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name but I guess we're stuck with it now). If you need a linked list rather than an array of physical addr/size tuples, you'll have to write a callback function that creates the list from the array. -- Ian From owner-freebsd-drivers@FreeBSD.ORG Tue Oct 14 00:19:35 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2BDE25A; Tue, 14 Oct 2014 00:19:35 +0000 (UTC) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94A168E2; Tue, 14 Oct 2014 00:19:35 +0000 (UTC) Received: by mail-oi0-f46.google.com with SMTP id h136so14801957oig.33 for ; Mon, 13 Oct 2014 17:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pf7re/j17h8+BUnecOmsnAEO46Zh8eGhei3dlvg7CxI=; b=iHWu9QOkiuUgwYff/vEFbMDduMlnTC31eB/oLNrX2VPOON8gUPOsz6m67mAUWN6KSj TiaTnMOickPrJAaq2f2M3c4FMFNAcALoHMhtmLXQ7XhwVfQyqiGDsNMbnZIy0irJd+i2 cMt6GMzHnGlM+Z/Yt3grnHxkqfgWETJdQKI8P/Vg4GflNzHKDudZQiv33S7RxJZ7eS3n W23mEg8an5NQmGyvsR0/vja3TXyd6YOn49mHNJxLyDsjlqgwT1pf59hWVtkwQnvCpQe3 YdI/iNw+93rclnClPqaaZEE6AkH0GEuvU1+cuvU5H36lRTIz966l2LsQvGopUgW9v+Z9 T2Zw== MIME-Version: 1.0 X-Received: by 10.182.105.135 with SMTP id gm7mr1483230obb.3.1413245974918; Mon, 13 Oct 2014 17:19:34 -0700 (PDT) Received: by 10.60.118.196 with HTTP; Mon, 13 Oct 2014 17:19:34 -0700 (PDT) In-Reply-To: <1413243678.12052.376.camel@revolution.hippie.lan> References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> <1413243678.12052.376.camel@revolution.hippie.lan> Date: Mon, 13 Oct 2014 21:19:34 -0300 Message-ID: Subject: Re: A few questions about SD/MMC drivers From: Martin Galvan To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-drivers@freebsd.org, freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:19:36 -0000 Well, that makes sense now. I'll try it out and let you know if it worked, thanks a ton! Just to be clear, though (and forgive me for my ignorance on this matter): is the "buffer" referenced in mmc_data always contiguous in memory? If so, why use segments/scatterlists at all? I thought the whole point of using descriptor lists in DMA transfers was to work with portions of memory that weren't next to each other. If the data we want to transfer is all in a single contiguous region, wouldn't a single descriptor with the required bus address and buffer length be enough? 2014-10-13 20:41 GMT-03:00 Ian Lepore : > On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: >> 2014-10-13 11:57 GMT-03:00 Warner Losh : >> > On Oct 12, 2014, at 11:24 PM, Martin Galvan wrote: >> >> The host found in Allwinner SoCs uses a DMA controller which works >> >> with a linked list of descriptors, each having info on a data buffer. >> >> In the Linux driver they allocate a coherent DMA buffer using >> >> dma_alloc_coherent to get both the virtual and bus addresses of the >> >> descriptor list. When it's time to do a DMA transfer, the Linux driver >> >> allocates a scatterlist with each entry being a buffer corresponding >> >> to a descriptor; it then loops through the descriptor list setting the >> >> "buffer pointer" field of each one to the bus address of the >> >> corresponding scatterlist entry, and the "next descriptor" to the bus >> >> address of the following descriptor. It's pretty neat, though it's >> >> worth mentioning the scatterlist that the MMC request handler maps >> >> already contains the virtual addresses of the requested buffers. >> >> >> >> Do we have anything like that on BSD? If not, what would be a simple >> >> algorithm to make this work? >> > >> > Pretty much all of that is covered in busdma(8). The mechanics are a bit >> > different than Linux, sure, but all that functionality is there. >> >> Actually, other than being able to alloc DMA buffers and get their bus >> addresses I didn't see anything like the Linux scatterlists. >> >> The main problem here is that the Linux mmc_data struct comes with an >> already-filled scatterlist. In that case, all I have to do is build >> the descriptor chain with the buffer addresses from the scatterlist >> entries. The only thing that's similar to that in the BSD API is >> mbuf_sg, which is used for network stuff. I didn't see anything that >> could allow me to build a descriptor chain-- all I saw was that the >> BSD mmc_data type has a buffer instead of a scatterlist. >> >> I'm thinking of telling the DMA controller to work with a single >> descriptor whose buffer is the one that comes inside mmc_data, but I'm >> not sure if this would be right. >> >> Again thanks a lot for your answers. > > When you map the buffer with bus_dmamap_load() your callback function is > passed an array of bus_dma_segment structures, each element of the array > is the physical address and size of a contiguous physical segment that > makes up part of the overall buffer. You are g'teed not to get more > segments than the limit specified in the dma tag used for the map (but > that just means the map function fails if there are too many segments, > not that some sort of automatic copy/consolidate is done for you). In > general you won't have a problem if you handle (512 * MAX_DATA + > PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name > but I guess we're stuck with it now). > > If you need a linked list rather than an array of physical addr/size > tuples, you'll have to write a callback function that creates the list > from the array. > > -- Ian > > From owner-freebsd-drivers@FreeBSD.ORG Tue Oct 14 00:29:30 2014 Return-Path: Delivered-To: freebsd-drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CEED395 for ; Tue, 14 Oct 2014 00:29:30 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 459CA9A8 for ; Tue, 14 Oct 2014 00:29:30 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id v10so6424014pde.20 for ; Mon, 13 Oct 2014 17:29:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=p+UVolV+nM2NvT9Y521GxFjKDtagQgiDCDtL7pAuKEM=; b=aGayN/ectMwEiwEYCMrxkXtZ0WhASMfnDiDKacAqihDCUZ+1PzHq/cHNwR9F79Bc12 3L4n1dZLzEt5ega1Lo8KTLKCLRKUn0hGo9G6OlQ+8IbkmXecFuxmSWnSColUX/IN/imm sbgOEyY9H7Vlqlr4GcsePoTghI+gtV9JKKtI6XvO9nT/PTp7nLGFoIBrmehJoapRxduq /ob77lrCJsn1sVU26cOgw3YJfhoIILBIGzgySOP6WXecnjDQ4g9CG2pEukpQCyin3ToQ cw6FM+EiXD0IuStqI4lQ9sBdQRwQFvRJzJUerq8Mhye5HqM8i89WLci5iA4yHFG2fLrY VRWw== X-Gm-Message-State: ALoCoQmw28NTXWmy74bJRNdms1Kk7UNYWRFEhasltHy5pUIZFYoiDRjSm5jXIfnl59psI+F4PD9H X-Received: by 10.66.254.136 with SMTP id ai8mr1389031pad.76.1413246134465; Mon, 13 Oct 2014 17:22:14 -0700 (PDT) Received: from [10.64.26.87] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id ne9sm134636pbc.87.2014.10.13.17.22.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 17:22:13 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: A few questions about SD/MMC drivers From: Warner Losh In-Reply-To: Date: Mon, 13 Oct 2014 18:22:10 -0600 Message-Id: References: <20141006171521.GD26076@kib.kiev.ua> <0B7F1C7B-7E38-48FD-B3CF-A4512A45E4C0@bsdimp.com> <1413243678.12052.376.camel@revolution.hippie.lan> To: Martin Galvan X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-drivers@freebsd.org, Ian Lepore , freebsd-embedded@freebsd.org X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:29:30 -0000 --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The buffer is always contiguous in virtual space, but maybe not = necessarily in physical space, hence the need for SG list. For buffers smaller than = one page, the difference doesn=92t matter :) But with multi-block support, = you=92ll need to cope with the difference. Warner On Oct 13, 2014, at 6:19 PM, Martin Galvan = wrote: > Well, that makes sense now. I'll try it out and let you know if it > worked, thanks a ton! >=20 > Just to be clear, though (and forgive me for my ignorance on this > matter): is the "buffer" referenced in mmc_data always contiguous in > memory? If so, why use segments/scatterlists at all? I thought the > whole point of using descriptor lists in DMA transfers was to work > with portions of memory that weren't next to each other. If the data > we want to transfer is all in a single contiguous region, wouldn't a > single descriptor with the required bus address and buffer length be > enough? >=20 > 2014-10-13 20:41 GMT-03:00 Ian Lepore : >> On Mon, 2014-10-13 at 20:25 -0300, Martin Galvan wrote: >>> 2014-10-13 11:57 GMT-03:00 Warner Losh : >>>> On Oct 12, 2014, at 11:24 PM, Martin Galvan = wrote: >>>>> The host found in Allwinner SoCs uses a DMA controller which works >>>>> with a linked list of descriptors, each having info on a data = buffer. >>>>> In the Linux driver they allocate a coherent DMA buffer using >>>>> dma_alloc_coherent to get both the virtual and bus addresses of = the >>>>> descriptor list. When it's time to do a DMA transfer, the Linux = driver >>>>> allocates a scatterlist with each entry being a buffer = corresponding >>>>> to a descriptor; it then loops through the descriptor list setting = the >>>>> "buffer pointer" field of each one to the bus address of the >>>>> corresponding scatterlist entry, and the "next descriptor" to the = bus >>>>> address of the following descriptor. It's pretty neat, though it's >>>>> worth mentioning the scatterlist that the MMC request handler maps >>>>> already contains the virtual addresses of the requested buffers. >>>>>=20 >>>>> Do we have anything like that on BSD? If not, what would be a = simple >>>>> algorithm to make this work? >>>>=20 >>>> Pretty much all of that is covered in busdma(8). The mechanics are = a bit >>>> different than Linux, sure, but all that functionality is there. >>>=20 >>> Actually, other than being able to alloc DMA buffers and get their = bus >>> addresses I didn't see anything like the Linux scatterlists. >>>=20 >>> The main problem here is that the Linux mmc_data struct comes with = an >>> already-filled scatterlist. In that case, all I have to do is build >>> the descriptor chain with the buffer addresses from the scatterlist >>> entries. The only thing that's similar to that in the BSD API is >>> mbuf_sg, which is used for network stuff. I didn't see anything that >>> could allow me to build a descriptor chain-- all I saw was that the >>> BSD mmc_data type has a buffer instead of a scatterlist. >>>=20 >>> I'm thinking of telling the DMA controller to work with a single >>> descriptor whose buffer is the one that comes inside mmc_data, but = I'm >>> not sure if this would be right. >>>=20 >>> Again thanks a lot for your answers. >>=20 >> When you map the buffer with bus_dmamap_load() your callback function = is >> passed an array of bus_dma_segment structures, each element of the = array >> is the physical address and size of a contiguous physical segment = that >> makes up part of the overall buffer. You are g'teed not to get more >> segments than the limit specified in the dma tag used for the map = (but >> that just means the map function fails if there are too many = segments, >> not that some sort of automatic copy/consolidate is done for you). = In >> general you won't have a problem if you handle (512 * MAX_DATA + >> PAGE_SIZE - 1) / PAGE_SIZE segments (MAX_DATA is a horrible ivar name >> but I guess we're stuck with it now). >>=20 >> If you need a linked list rather than an array of physical addr/size >> tuples, you'll have to write a callback function that creates the = list >> from the array. >>=20 >> -- Ian >>=20 >>=20 --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUPGyyAAoJEGwc0Sh9sBEAuQEQALg1smhHq8LbE8b+SOrzhsKP qPjakDbn8lUk+hF8k7dXEoqNrPzFmLNt7OSXX1GI5CgiAYsUrZAjNeJJc3xpaUoQ g4q6EHpNhJCcJlc9NgiJXTRCQh1NeKdt4BHl4C0eIP0CqKywI5EMTBqMl4RW6yjG vSDaKu66FD5YfHkpi0m1R0eWOVExDSv6W5r/s7BeJAGG/mrOPRFO2RQKwbSIQl2a X7NCTsAYOGklrqZ0MaEhWfvLfZ5YnBL0eZrmjUOxidkyNXN/yp9qaKqGXlsdBp7C trpGgXsHeIl3DdWS17wzm4xjg0owbIOyMFgr7NixOxR2I/IDlpcMEHXxhCdQcXZT 3p+ScbFHI/XlF2yAK+v9NnQGDlinw74LKYD5HiXEkzLGtgTI6SlN8WlA6fjY3bNU BLEDyFDuvH4lzsdITknxwLmUGI7rmXRXzDMRq0Z2lXHpI99mJdO4KCt8dXXXs+9J M9xU28C+hJ/wJYF8zqjleN91LH6a4cPhk0KKD9c76JLyPYun6zPC2dEZpCOOAeSi 1Q6dQCIqMei3fmE15NQA48BEKPX66JleDF51oCyYdFoUhXJjCYPzERMSmsWZs8/r CEjEQkAssaoqD5Qmg7ackCsAhbjqU/WLQ7X5iu0FIJwk53nU1FU1Jbnp0LR0/oIu D7hqPzufhWAQcmIm8P1v =r/BK -----END PGP SIGNATURE----- --Apple-Mail=_574CE74E-C0F1-494A-A67D-359860E4B1C7-- From owner-freebsd-drivers@FreeBSD.ORG Sat Oct 18 17:26:33 2014 Return-Path: Delivered-To: drivers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A800DFE for ; Sat, 18 Oct 2014 17:26:33 +0000 (UTC) Received: from deep.dns247.com (deep.dns247.com [202.0.103.109]) by mx1.freebsd.org (Postfix) with ESMTP id F00BC6DE for ; Sat, 18 Oct 2014 17:26:32 +0000 (UTC) Received: by deep.dns247.com for ; Sat, 18 Oct 2014 17:05:39 GMT Message-ID: <20141018222915-1.1.2j.67px.0.rctwou3im3@openemm.invalid> Date: Sat, 18 Oct 2014 17:05:39 GMT From: "Mahak" To: Subject: Mobile Apps Development X-Mailer: OpenEMM V2013 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Oct 2014 17:26:33 -0000 Hello, Hope You Are Well! We're a lot different than most other developers in that we don't give you an hourly rate and then leave you in the dark about how many hours you're going to have to pay for to develop your project. We appreciate that in today's economy businesses want to know total cost before they decide to become customers. We offer the following services, all at Flat Rate prices: =E2=80=A2 Mobile Application Development =E2=80=A2 E-commerce Website Development =E2=80=A2 Customized Software Development =E2=80=A2 ERP Software Development =E2=80=A2 Share Point Development =E2=80=A2 Content Writing =E2=80=A2 Graphic Design Please reply back to this email today and let me send you links to our portfolio and vast gallery of our many happy customers. Also, if you send me your detailed project specifications I will be more than happy to provide you with a flat rate price. I appreciate your time and consideration, should you wish that I take your name off my contact list, simply let me know in a reply email. Kind Regards, Mahak Business Consultant Email: - asktosolution@gmail.com Disclaimer: The CAN-SPAM Act of 2003 (Controlling the Assault of Non- Solicited Pornography and Marketing Act) establishes requirements for those who send commercial email, spells out penalties for spammers and companies whose products are advertised in spam if they violate the law, and gives consumers the right to ask mailers to stop spamming them. The above mail is in accordance to the Can Spam act of 2003: There are no deceptive subject lines and is a manual process through our efforts on World Wide Web. You can opt out by sending to asktosolution@gmail.com to ensure you will not receive any such mails.