From owner-freebsd-embedded@FreeBSD.ORG Tue Oct 14 00:28:34 2014 Return-Path: Delivered-To: freebsd-embedded@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 13771358 for ; Tue, 14 Oct 2014 00:28:34 +0000 (UTC) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) (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 D000099F for ; Tue, 14 Oct 2014 00:28:33 +0000 (UTC) Received: by mail-pd0-f172.google.com with SMTP id ft15so6437844pdb.17 for ; Mon, 13 Oct 2014 17:28:27 -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=FW9zE4WD3mRAdqNGV0R5oaKeJUoZUyQE/KV8FZhVgTjStD76+TSS9vHsjisZO6IVZB hqAQ2vrIycB0Aa9qlAu2hXeDZKsvDleWdEnGAbMFHqkmQ5A5OZR1/Lxi98BJzL3Xbc/+ +yshkiYCH5CRrYzc0MA5YX024+SFmm/3Yljq6aGe92hgDX47Ntxcjsm4BJwRERcj21iY ij4fZzbNcq+6iMgIjkj2ww/28beSiKRoYj5C2xjizB4LK2itMyoh0eCKSzd02inpobFB oFbCRD6W8UFwIyqi0Lunu5Pt4wuN9TkMKLvnAS4KdbMrmwQGIv8+b4O0KgMgMhHKnDMn 4+WQ== X-Gm-Message-State: ALoCoQlx8lDZfzpqvOAvLdoeQtL39gkbWlOKFvYvhB9Lp17ey4sQNcU3wiMxrpGf6G4haOOeHVEx 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: Konstantin Belousov , freebsd-drivers@freebsd.org, Ian Lepore , freebsd-embedded@freebsd.org X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:28:34 -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--