From owner-freebsd-embedded@FreeBSD.ORG Sun Oct 6 20:33:26 2013 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 521C69DB; Sun, 6 Oct 2013 20:33:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B8F132E25; Sun, 6 Oct 2013 20:33:25 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d41so2783396eek.22 for ; Sun, 06 Oct 2013 13:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YiWKo+3mjGy4oLkmZgo25NkeeTWslnj8Xx21dCq+Lew=; b=NMKax8ugYiuv8XznrZj3+yoR4260dp7aR+E8ioayCNTqrJndmCDOrnAxLhghWZ9USe dsJSKRgV9+PPlnkZWeVDctxpmaATiyA+9Pxe2YbqEm05oLDDG3MtBsWVSC1q5R0GX1/1 roOw+soVJ3yGhgHF25XPvv0V1kXFEPJ3apy6YTuy149pOJRI9LFFfUj0eBRs4+vWlclJ d965d6k7BdL7d5qL/wf/tOOqbE3CBc3W1GCj+5J8yAC8AwLAP7NU0m+j3uYN0igfXPho 140iecP1twQKnQiLVtEmsXv10gy+hR3UWYrYlPRzL5K4kjuG2KYJkMKcPrbEQHEG5BYj eZXw== X-Received: by 10.15.94.201 with SMTP id bb49mr43380738eeb.23.1381091604178; Sun, 06 Oct 2013 13:33:24 -0700 (PDT) Received: from mavbook.mavhome.dp.ua ([46.211.77.102]) by mx.google.com with ESMTPSA id bn13sm54861981eeb.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Oct 2013 13:33:23 -0700 (PDT) Sender: Alexander Motin Message-ID: <5251C911.6020003@FreeBSD.org> Date: Sun, 06 Oct 2013 23:33:21 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130616 Thunderbird/17.0.6 MIME-Version: 1.0 To: Ilya Bakulin Subject: Re: SDIO for FreeBSD References: <5251A9D3.1080803@bakulin.de> In-Reply-To: <5251A9D3.1080803@bakulin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-embedded@freebsd.org" X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Oct 2013 20:33:26 -0000 On 06.10.2013 21:20, Ilya Bakulin wrote: > Just a quick status update. > I have managed to make interrupts work. Was rather silly copy&paste mistake. > > 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. I am sorry, can't hold from rephrasing the joke: how many threads does it take to handle an interrupt? ;) IMHO 3 threads used to handle single hardware interrupt is a good point to invent something better. That would be easy if controller and MMC layers used the same lock and MMC could send interrupt status request asynchronously just from the ISR, but they don't. May be things could be much more simple if if would be controller driver obligation to read interrupt status from the card instead of jumping up and down over the stack and having to use additional threads to decouple the locks? That is like in CAM for both ATA and SCSI now it is controller driver duty to fetch errors details from the device, even sending additional commands if needed. > 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 GitHub. > 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. -- Alexander Motin