MMC/SDIO stack under CAM

Sun Feb 14 06:33:53 UTC 2016

On Fri, Feb 12, 2016 at 11:48 PM, Russell Haley <russ.haley at gmail.com>
wrote:

> On Fri, Feb 12, 2016 at 8:16 PM, Adrian Chadd <adrian.chadd at gmail.com>
> wrote:
> > On 12 February 2016 at 19:58, Russell Haley <russ.haley at gmail.com>
> wrote:
> >> 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"?
> >
> > nope. there's a lot more to it than that. But it's a good start -
> > getting the driver up and doing IO to the card is a big step.
> >
> >
> >
> > -a
> >
> Okay, thanks. But if I include his CAM driver and then use the patch
> below for IMX6 on my Hummingboard, I would be able to test the driver?
> Will a simple kldstat be enough to verify I am using his driver or is
> there something more direct in dtrace?
>

"camcontrol devlist" would let you know for sure.

Warner

> Thanks,
>
> Russ
>
> >> Thanks,
> >> Russ
> >>
> >> Sent from my BlackBerry 10 smartphone on the Koodo network.
> >>   Original Message
> >> From: Ilya Bakulin
> >> Sent: Thursday, February 11, 2016 10:43 AM
> >> To: Lundberg, Johannes
> >> Cc: Adrian Chadd; freebsd-hackers at freebsd.org; Alexander Motin;
> freebsd-arm at freebsd.org
> >> Subject: Re: MMC/SDIO stack under CAM
> >>
> >> 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
> really 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. For example, iMX6 SDHCI needed only a couple of lines:
> https://github.com/kibab/freebsd/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" <
> johannes at 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 at 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
> >>>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 <ilya at 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
> >>>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 at freebsd.org mailing list
> >>>> > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> >>>> > To unsubscribe, send any mail to "
> >>>> freebsd-hackers-unsubscribe at freebsd.org"
> >>>> >
> >>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Ilya Bakulin
> >>>>
> >>>>
> >>>>
> >>>
> >>>--
> >>>=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> >>>秘密保持について：この電子メールは、名宛人に送信したものであり、秘匿特権の対象となる情報を含んでいます。
> >>>もし、名宛人以外の方が受信された場合、このメールの破棄、およびこのメールに関する一切の開示、
> >>>複写、配布、その他の利用、または記載内容に基づくいかなる行動もされないようお願い申し上げます。
> >>>---
> >>>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.
> >>
> >> --
> >> Простите за краткость, создано в K-9 Mail.
> >> _______________________________________________
> >> freebsd-arm at freebsd.org mailing list
> >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>