From owner-freebsd-arm@freebsd.org Sat Feb 13 03:58:10 2016 Return-Path: Delivered-To: freebsd-arm@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 36AC5AA5AA3; Sat, 13 Feb 2016 03:58:10 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05AC81CF3; Sat, 13 Feb 2016 03:58:09 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-io0-x234.google.com with SMTP id l127so110741344iof.3; Fri, 12 Feb 2016 19:58:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=Xp55/YuHn5rPNs5/9VbDhKFAh+fvTyFLgu2rKstmg2U=; b=Szwgu/DCHIdoILcZO8a85wOtTGgndY3J4YFxLY0elVoa0IuTvCJN3cAgL4sjw66SlM 8EycPnbHfSc7X7k1WIkBRPBwjKMRTB3/zOFL/4BlbW+IRC3x0gRZS3gzL7qztzUWT8v3 ZrNG7HNsRq+Hy+jRw6q8xHMDaYwrG4BwwSzItmC1rMt9yUFnMkWbLF7QGKo6KUMMqf0z nC65PieLV5jrZbop9NAmONQRuzUFD3FXyUzLxQ9Z53HDVlsg4FaWytDXFa135KZ2dEzY DkCRLNBT0QCYsUJsHQd6/rPrXSQN1OviuiUaH0m198Gpvd9hj3nEUrNejFBsL1Jv41dP v/sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:message-id:date:subject:from:in-reply-to :references:to:cc; bh=Xp55/YuHn5rPNs5/9VbDhKFAh+fvTyFLgu2rKstmg2U=; b=aPfheEiNSCzHUmjg2niPlrhMaAUAvW2+s+gD1mv98qmPXg7YzSvb08c+8sFfEjtg1u 0XAYcImzn0RdMU74Tfn4nhHLpBt+ukMslBzTUw7RMD6U4znJKa0CP49+ZsirpXLj/+aa 7O1aDg50MplwSdUuVE9CIdUB/EzoeJftSCEwd30R7Bs5R/VSiw2n2j9phwB+YQ7yk/HO wx5W8KjUDGlI3ixVFbgKwsPD6T2zTzxK2WrLYgeXDpfheYVJLphdKWxB5IC6EJKlhXc0 ryw0/Q2seYinAVgXsVJFhyIwSgAThYwF5YN7rQ4B2zGapuZEfs3fsXKYeXDfPi5OWOs+ QMPA== X-Gm-Message-State: AG10YOQCBN9J/Zy78AN4Amf8gD/Kf+vI49P7umawswJUT5tHx9KO3vqz4AcqbRk7QMdUIA== X-Received: by 10.107.152.142 with SMTP id a136mr6721597ioe.84.1455335889108; Fri, 12 Feb 2016 19:58:09 -0800 (PST) Received: from [127.0.0.1] ([209.52.88.27]) by smtp.gmail.com with ESMTPSA id v68sm7511666ioi.23.2016.02.12.19.58.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Feb 2016 19:58:08 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160213035806.4403283.12124.2928@gmail.com> Date: Fri, 12 Feb 2016 19:58:06 -0800 Subject: Re: MMC/SDIO stack under CAM From: Russell Haley In-Reply-To: References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> To: Ilya Bakulin , "Lundberg, Johannes" Cc: Adrian Chadd , freebsd-hackers@freebsd.org, Alexander Motin , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Feb 2016 03:58:10 -0000 Hi Ilya, so does that mean I can take a linux driver for an SDIO wifi card = and build it using a reference to your library and everything should "just = work"? Thanks, Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Koodo=C2=A0network. =C2=A0 Original Message =C2=A0 From: Ilya Bakulin Sent: Thursday, February 11, 2016 10:43 AM To: Lundberg, Johannes Cc: Adrian Chadd; freebsd-hackers@freebsd.org; Alexander Motin; freebsd-arm= @freebsd.org Subject: Re: MMC/SDIO stack under CAM Hi Johannes, My work doesn't include writing drivers for SDHCI controllers. But if the c= ontroller on your new boards is supported by FreeBSD, then you can really t= est the new stack! Especially if the controller driver for your board is ba= sed on dev/sdhci, adapting it to work with the new stack is trivial. For ex= ample, iMX6 SDHCI needed only a couple of lines: https://github.com/kibab/f= reebsd/commit/df6d8d534740aa3633979da0a9d0ca00b60db0e9 Please let me know when you get the new boards and we will figure out what = we need. On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" wrote: >Hi Ilya > >This is great! > >I've got a Tronsmart ARA X5 and just purchased a few UP > >boards >and it would be really nice if I could utilize the onboard eMMC. These >are >all Intel Cherrytrail platforms. > >Please let me know if there's anything (testing?) I can do to speed up >the >process. > > > >-- >Name: Johannes Lundberg >Position: Mirama project leader >Phone: +1-408-636-2161 >Skype: brilliantjohannes >Online: LinkedIn >Facebook > Reddit > Twitter > GitHub > >GitLab >Company: Mirama Brilliantservice US > Brilliantservice JP > > >On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin wrote: > >> So, more than one year has passed, and I'd like to resurrect this >work >> and move forward. >> >> I have uploaded a new diff and created a completely new revision to >> track the development: https://reviews.freebsd.org/D4761 >> >> What it is able to do now: >> >> * Read/write on SD/SDHC/MMC cards! >> * Detect SDIO cards and create devices that correspond to SDIO >functions >> >> This all works only on BeagleBone currently, because some changes >need >> to be done in each SDHCI-compliant driver to make it interact with >CAM. >> I have purchased a Wandboard Quad that has an integrated SDIO WiFi >chip, >> so I hope to tweak its SDHCI driver as well. >> >> I haven't profiled the stack because: >> * Now we have only SD/MMC cards that are slow anyway; >> * I don't know how to do it in FreeBSD :-) >> >> Please review this diff and tell what you think! >> >> On 01/03/14 18:05, Adrian Chadd wrote: >> > On 1 March 2014 08:46, Ilya Bakulin wrote: >> >> Hi Adrian, >> >> >> >> On 24.02.14, 16:59, Adrian Chadd wrote: >> >>> hi, >> >>> >> >>> Let me just reiterate some .. well, experience doing this stuff >at QCA. >> >>> >> >>> You really, absolutely don't want too much overhead in the >MMC/SDIO >> >>> path between whatever is issuing things and the network driver. >> >>> >> >>> There was significant performance work done at QCA on a local >MMC/SDIO >> >>> driver and bus to get extremely low latency and CPU utilisation >when >> >>> pushing around small transactions. The current CAM locking model >is >> >>> not geared towards getting to high transaction rates. >> >> So here you mean some work done on Linux MMC/SDIO stack by QCA >> >> which made it far better than current Linux MMC stack in terms of >> >> high SDIO I/O rates? >> > Yup. The stock MMC stack/driver in Linux wasn't "fast" enough at >small >> > transactions to sustain the wifi speeds customers required. >> > >> >>> You may think this is a very architecturally pretty solution and >it >> >>> indeed may be. But if it doesn't perform as well as the existing >local >> >>> hacks that vendors have done, no company deploying this hardware >is >> >>> going to want to use it. They'll end up realising there's this >massive >> >>> CAM storage layer in between and either have to sit down to rip >it up >> >>> and replace it with something lightweight, or they'll say "screw >it" >> >>> and go back to the vendor supplied hacked up Linux solution. >> >> I think that if the "architecturally pretty solution" behaves >worse than >> >> some ugly hacks, then it may be not so pretty or the architecture >is >> >> just broken >> >> by design. >> >> >> >>> So I highly recommend you profile things - and profile things >with >> >>> lots of small transactions. If the CAM overhead is more than a >tiny, >> >>> tiny fraction of CPU at 25,000 pps, your solution won't scale. >:-) >> >> I don't really know what to compare with. For MMC/SD cards it is >pretty >> >> obvious, but then these cards will be likely the bottleneck, not >the >> stack. >> >> And the only goal would be to not make the stack slower than it is >now. >> >> But, as ATA devices are much faster than MMC/SD, I don't think >this will >> >> be a problem. >> >> >> >> For SDIO things are different. But we don't have any drivers >(yet), >> except >> >> mv_sdiowl that I'm writing, to test on. So I have to bring the >SDIO >> >> stack on CAM, >> >> than bring mv_sdiowl to the state when it can actually transmit >the >> >> data, and then >> >> compare performance with the vendor-supplied Linux driver. >> >> We'll see then if there is a room for improvement... >> > That sounds like a plan. >> > >> > Just note that although storage looks like it's doing much more >> > throughput, the IO size also matters. As I said above, it's not >> > uncommon to have > 1000 receive frames a second on 802.11n; and >that >> > can peak much higher than that. That's not the kind of IO rate you >see >> > on SD cards. :-) >> > >> > >> > >> > -a >> > _______________________________________________ >> > freebsd-hackers@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> > To unsubscribe, send any mail to " >> freebsd-hackers-unsubscribe@freebsd.org" >> > >> >> >> -- >> Regards, >> Ilya Bakulin >> >> >> > >--=20 >=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- >=E7=A7=98=E5=AF=86=E4=BF=9D=E6=8C=81=E3=81=AB=E3=81=A4=E3=81=84=E3=81=A6= =EF=BC=9A=E3=81=93=E3=81=AE=E9=9B=BB=E5=AD=90=E3=83=A1=E3=83=BC=E3=83=AB=E3= =81=AF=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E3=81=AB=E9=80=81=E4=BF=A1=E3=81= =97=E3=81=9F=E3=82=82=E3=81=AE=E3=81=A7=E3=81=82=E3=82=8A=E3=80=81=E7=A7=98= =E5=8C=BF=E7=89=B9=E6=A8=A9=E3=81=AE=E5=AF=BE=E8=B1=A1=E3=81=A8=E3=81=AA=E3= =82=8B=E6=83=85=E5=A0=B1=E3=82=92=E5=90=AB=E3=82=93=E3=81=A7=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 >=E3=82=82=E3=81=97=E3=80=81=E5=90=8D=E5=AE=9B=E4=BA=BA=E4=BB=A5=E5=A4=96= =E3=81=AE=E6=96=B9=E3=81=8C=E5=8F=97=E4=BF=A1=E3=81=95=E3=82=8C=E3=81=9F=E5= =A0=B4=E5=90=88=E3=80=81=E3=81=93=E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81= =AE=E7=A0=B4=E6=A3=84=E3=80=81=E3=81=8A=E3=82=88=E3=81=B3=E3=81=93=E3=81=AE= =E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AB=E9=96=A2=E3=81=99=E3=82=8B=E4=B8=80=E5= =88=87=E3=81=AE=E9=96=8B=E7=A4=BA=E3=80=81 >=E8=A4=87=E5=86=99=E3=80=81=E9=85=8D=E5=B8=83=E3=80=81=E3=81=9D=E3=81=AE= =E4=BB=96=E3=81=AE=E5=88=A9=E7=94=A8=E3=80=81=E3=81=BE=E3=81=9F=E3=81=AF=E8= =A8=98=E8=BC=89=E5=86=85=E5=AE=B9=E3=81=AB=E5=9F=BA=E3=81=A5=E3=81=8F=E3=81= =84=E3=81=8B=E3=81=AA=E3=82=8B=E8=A1=8C=E5=8B=95=E3=82=82=E3=81=95=E3=82=8C= =E3=81=AA=E3=81=84=E3=82=88=E3=81=86=E3=81=8A=E9=A1=98=E3=81=84=E7=94=B3=E3= =81=97=E4=B8=8A=E3=81=92=E3=81=BE=E3=81=99=E3=80=82 >--- >CONFIDENTIALITY NOTE: The information in this email is confidential >and intended solely for the addressee. >Disclosure, copying, distribution or any other action of use of this >email by person other than intended recipient, is prohibited. >If you are not the intended recipient and have received this email in >error, please destroy the original message. --=20 =D0=9F=D1=80=D0=BE=D1=81=D1=82=D0=B8=D1=82=D0=B5 =D0=B7=D0=B0 =D0=BA=D1=80= =D0=B0=D1=82=D0=BA=D0=BE=D1=81=D1=82=D1=8C, =D1=81=D0=BE=D0=B7=D0=B4=D0=B0= =D0=BD=D0=BE =D0=B2 K-9 Mail. _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"