Date: Thu, 11 Feb 2016 10:55:11 -0800 From: "Lundberg, Johannes" <johannes@brilliantservice.co.jp> To: Ilya Bakulin <ilya@bakulin.de> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Adrian Chadd <adrian.chadd@gmail.com>, Alexander Motin <mav@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: MMC/SDIO stack under CAM Message-ID: <CAASDrVm6HNUzg-TQjeeNyVkF1s6tOQsRCcDZCJTr7zOMCcJ5%2BA@mail.gmail.com> In-Reply-To: <DD0089CC-19BF-4179-9A05-6B920B1DF7F9@bakulin.de> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <CAJ-VmomNzCMc1T=0jAnyd_uGXbvgeTzZTtmhUPSvZ0DKUEjtKg@mail.gmail.com> <53120EE8.1080600@bakulin.de> <CAJ-VmonPkdVVq7nC3FdopcgzmSTsj3gTO=Cghx-62XS5K25YQg@mail.gmail.com> <5688F015.4090002@bakulin.de> <CAASDrVkHKzt4LKnLEFbwZ0gWRpwEOcpjaCFaOTg%2Bs2DACebopA@mail.gmail.com> <DD0089CC-19BF-4179-9A05-6B920B1DF7F9@bakulin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Ilya The controller is Intel, https://pci-ids.ucw.cz/read/PC/8086/0f14 It was added in Linux some time ago http://lxr.free-electrons.com/source/drivers/mmc/host/sdhci-acpi.c I'm not sure how much work is needed to get the controller working...? I'm kind of new to device driver development. -- Name: Johannes Lundberg Position: Mirama project leader Phone: +1-408-636-2161 Skype: brilliantjohannes Online: LinkedIn <http://jp.linkedin.com/in/lundbergjohannes>; Facebook <https://www.facebook.com/miramaone>; Reddit <https://www.reddit.com/user/yohanesu75/>; Twitter <https://twitter.com/Yohanesu75Tweet>; GitHub <https://github.com/yohanesu75= > GitLab <https://gitlab.com/u/johannes_lundberg>; Company: Mirama <http://mira.ma>; Brilliantservice US <http://www.brilliantserviceusa.com>; Brilliantservice JP <http://www.brilliantservice.co.jp>; On Thu, Feb 11, 2016 at 10:42 AM, Ilya Bakulin <ilya@bakulin.de> wrote: > Hi Johannes, > > My work doesn't include writing drivers for SDHCI controllers. But if the > controller on your new boards is supported by FreeBSD, then you can reall= y > test the new stack! Especially if the controller driver for your board is > based on dev/sdhci, adapting it to work with the new stack is trivial. Fo= r > example, iMX6 SDHCI needed only a couple of lines: > https://github.com/kibab/freebsd/commit/df6d8d534740aa3633979da0a9d0ca00b= 60db0e9 > > Please let me know when you get the new boards and we will figure out wha= t > we need. > > On February 11, 2016 3:17:22 AM GMT+01:00, "Lundberg, Johannes" < > johannes@brilliantservice.co.jp> wrote: > >> Hi Ilya >> >> This is great! >> >> I've got a Tronsmart ARA X5 and just purchased a few UP >> <http://up-shop.org/up-boards/2-up-board-2gb-16-gb-emmc-memory.html>; >> 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 <http://jp.linkedin.com/in/lundbergjohannes>; Facebook >> <https://www.facebook.com/miramaone>; Reddit >> <https://www.reddit.com/user/yohanesu75/>; Twitter >> <https://twitter.com/Yohanesu75Tweet>; GitHub >> <https://github.com/yohanesu75>; GitLab >> <https://gitlab.com/u/johannes_lundberg>; >> Company: Mirama <http://mira.ma>; Brilliantservice US >> <http://www.brilliantserviceusa.com>; Brilliantservice JP >> <http://www.brilliantservice.co.jp>; >> >> On Sun, Jan 3, 2016 at 1:55 AM, Ilya Bakulin <ilya@bakulin.de> 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 function= s >>> >>> 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 <ilya@bakulin.de> 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 whe= n >>> >>> 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 smal= l >>> > 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 se= e >>> > 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 >>> >>> >>> >> >> =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. > > > -- > =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. > --=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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAASDrVm6HNUzg-TQjeeNyVkF1s6tOQsRCcDZCJTr7zOMCcJ5%2BA>