Date: Sun, 06 Oct 2013 20:20:03 +0200 From: Ilya Bakulin <ilya@bakulin.de> To: Warner Losh <imp@bsdimp.com>, Alexander Motin <mav@freebsd.org>, Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-embedded@freebsd.org" <freebsd-embedded@freebsd.org> Subject: SDIO for FreeBSD Message-ID: <5251A9D3.1080803@bakulin.de>
next in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just a quick status update. I have managed to make interrupts work. Was rather silly copy&paste mista= ke. So now I'm able to issue a command to the WiFi card and actually get an interrupt from the controller. I have added several bus methods for setting up interrupt handlers and allocating resources, both to the MMC stack and to my WiFi driver, as well as mv_sdio SDIO controller driver for DreamPlug. The code is kept under [1], as usual. I have the fully working stack now and I'd like to discuss the locking model for SDIO. So, the SDIO controller detects an interrupt. SDIO controller driver handles it its own interrupt thread (I assume that we use ITHREAD ISRs). All the controller can do at this stage is: 1. read device registers to get the interrupt cause; 2. clear/set some bits in device registers; 3. If there was a command- or data-related interrupt, call req->done() method of struct mmc_request, which sets MMC_REQ_DONE flag in the request structure and then calls wakeup() on mmc_request. This is what actually happens now. MMC stack which is doing msleep() waiting for MMC_REQ_DONE flag detects this flag and continues with request processing, returning a result to the upper layer. See mmc_wakeup() and mmc_wait_for_req() in sys/dev/mmc/mmc.c Everything is syncronous at this point, no complications. Now the SDIO case. The controller can detect an interrupt at any time, then it notifies the MMC stack about it. This happens in the ITHREAD of SDIO controller's ISR. In MMC stack, we now want to read the "Penging interrupts" register to figure out which function has raised the interrupt. We cannot, however, issue another request to SDIO controller since that inhibits sleeping and we cannot sleep in ISR. We will also need to call ISRs of our child devices that can possibly do another weird stuff. So I propose adding a dedicated thread in MMC layer that will just process the interrupts from the card. It can be started on MMC stack attach, grab MMC lock and then just sleep on condition variable (which will be per-bus, ie for each SDIO card since there can only be one SD[IO] card on the bus), giving the lock back. When the MMC stack's ISR is called by SDIO controller, it will just cv_signal() that variable and do nothing more than that. The MMC interrupt servicing thread will then wakeup (and grab the MMC lock!), it will be able to do another MMC request to read "pending interrupts" register and call the ISRs of respective child drivers. We expect them to be quick and probably do the similar stuff -- just signaling CVs and/or taskqueue_enqueue()-ing interrupt processing tasks. Sorry if I totally misunderstand the concept here, please tell your opinions. [1] https://github.com/kibab/freebsd/compare/master...kibab-dplug Note that I have made a rebase and pushed the rebased branch back to GitH= ub. This is an epic fuckup and it requires everyone to delete the local branch and pull it once again, as the IDs have changed. Sorry for that, I will do merges next time. -- Regards, Ilya Bakulin --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJRqdcACgkQo9vlj1oadwgR+wCghJ8m+uzm7xi7e9hy7IZSV1sQ BQEAn27H8ajw6DEFcMhuyQ/R3pVw2V3s =Tlri -----END PGP SIGNATURE----- --GDMAeSsRCntmpIADPiVqHTMKix2lmq8EV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5251A9D3.1080803>