From owner-freebsd-drivers@freebsd.org Fri Dec 23 21:40:01 2016 Return-Path: Delivered-To: freebsd-drivers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F416FC8E710 for ; Fri, 23 Dec 2016 21:40:00 +0000 (UTC) (envelope-from xmoseby@yahoo.se) Received: from nm1-vm5.bullet.mail.ir2.yahoo.com (nm1-vm5.bullet.mail.ir2.yahoo.com [212.82.96.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 67F871789 for ; Fri, 23 Dec 2016 21:39:59 +0000 (UTC) (envelope-from xmoseby@yahoo.se) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.se; s=s2048; t=1482528344; bh=UvuXK33YA2oV8vYfNxBArMTHb1zH7AYbDX9tj6DfJCM=; h=Date:From:Reply-To:To:Cc:Subject:References:From:Subject; b=AspO/xGaWUJ7w40vzGLqeqXrxYvczt2OWStoraLhsykquVc0feUQCXTJSmv51PRWG09VBlG1u9txiwQ91zb78q1GFgsSYXJ4hmFBZW8RjtvgLbwGldqNYwqAVFzPZclQCf0iUSnbyGNpTby6zl9kA6TMMiIRtvWxOun64M9pFAXn9eQrzdaGfLcJ4NfSt59sFDpIkJVNQiLYqP+Snv0l+alD4O88S3oJ6wJOz69o8B6rzmqB+JQ7+8DL3R3paKXPdso4g+w8Iql2by1t0NGOgceKIT+6aWMciJbFSXZj0+N9Y4w8WO0dqxFbNfQ8FoY73eo5npCQ9z4cdIFf476yjQ== Received: from [212.82.98.124] by nm1.bullet.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 Received: from [212.82.98.79] by tm17.bullet.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 Received: from [127.0.0.1] by omp1016.mail.ir2.yahoo.com with NNFMP; 23 Dec 2016 21:25:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 297022.40722.bm@omp1016.mail.ir2.yahoo.com X-YMail-OSG: IzX0bjQVM1mRTeDdGNRLzJon0GiXFbx0We4oVZszI4Jbyai4Tp7KnP4S1IgBNwp y2R8w0MTYFMkzQi_sfgfljva3xzPJetC.IdNMudd4IsyScFNWIlT4uyQxGtCAFE2ZgtWay_YejU4 4ikzRDIoaSVi4lJqS69XSsle2ptmCLAMAacMbTPGvIUiGXLVO8lpTGDrzdlkdhC_hoxxQHzu5uKo gC2ewCZJC5uipndU8mlNbHqLTvRW2inlu3u9LhLRVoD5daIKsh7hLIh7iog..tPf8AcZl7sadvVi .Zfdt5Uf4FHwBGwzsX3WL1V6rQSJeLTB81OeZerjMtudppGVJONRD5Ij_kMQdd6k_Ia5xTgj6q4O cPDYxRz7FxMnyx0_zRE4LpzVGixv71UUu0r4x9zISwn0SBI1A6V4WW5uC5RpYztIw_VY12kEW3Pl wCCK7wxM7SSIsxbvLVhbFQDuBHLDvO4xVb5cnZfLRBbn1kq5iszBGWe7eW.Nfow.MTQE.G3duG6F y8svMehIxvR89Njrh96w1CaxS5uA- Received: from jws700061.mail.ir2.yahoo.com by sendmailws164.mail.ir2.yahoo.com; Fri, 23 Dec 2016 21:25:43 +0000; 1482528343.745 Date: Fri, 23 Dec 2016 21:25:43 +0000 (UTC) From: tony moseby Reply-To: tony moseby To: Warner Losh , Martin Galvan Cc: "freebsd-drivers@freebsd.org" , Ian Lepore , "freebsd-embedded@freebsd.org" Message-ID: <2053136483.1957700.1482528343527@mail.yahoo.com> Subject: SV: A few questions about SD/MMC drivers MIME-Version: 1.0 References: <2053136483.1957700.1482528343527.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-drivers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Writing device drivers for FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2016 21:40:01 -0000 Hello Ian, I can read that you have been involved in a similar problem that I am facin= g now.I am running FreeBSD 8.2 and a armv5TE (marvel mv78100), I have an ss= d disk(4Giga).While running the system and doing disk acesses=C2=A0 after s= ometime (can be days or at least several hours)the system total freezes.Ser= ial port freezes and=C2=A0 ethernet freezes.(just internal connections, no = public). If I do not use the disk, this(the freeze) do not occur.My watchdog is disa= bled , so I am suspecting that the kernel crashes and that is the cause of = the freeze.I connected an emulator to=C2=A0 the board, but whenever the fre= eze occur,the emulator looses also contactwith the CPU.I have tested to do = a lot of read/write towards the ssd,often this also causes freeze, but for = a coupleof times I can see the kernel crashing with alignment fault 1.Do yo= u have any ideas?ThanksBR/T =20 Den tisdag, 14 oktober 2014 2:29 skrev Warner Losh : =20 The buffer is always contiguous in virtual space, but maybe not necessaril= y in physical space, hence the need for SG list. For buffers smaller than one page, the difference doesn=E2=80=99t matter :) But with multi-block support= , you=E2=80=99ll 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 wr= ote: >>>>> 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 drive= r >>>>> allocates a scatterlist with each entry being a buffer corresponding >>>>> to a descriptor; it then loops through the descriptor list setting th= e >>>>> "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 b= it >>>> 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.=C2=A0 You are g'teed not to get mor= e >> 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).=C2=A0= 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 =20