From patchwork Sun Aug 28 10:50:54 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Per Forlin X-Patchwork-Id: 1105492 Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) by demeter2.kernel.org (8.14.4/8.14.4) with ESMTP id p7SApM7i017330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 28 Aug 2011 10:51:43 GMT Received: from canuck.infradead.org ([2001:4978:20e::1]) by merlin.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1QxcxD-0003Yf-Jl; Sun, 28 Aug 2011 10:51:03 +0000 Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1QxcxD-0000zh-4o; Sun, 28 Aug 2011 10:51:03 +0000 Received: from mail-gy0-f177.google.com ([209.85.160.177]) by canuck.infradead.org with esmtps (Exim 4.76 #1 (Red Hat Linux)) id 1Qxcx9-0000zN-3o for linux-arm-kernel@lists.infradead.org; Sun, 28 Aug 2011 10:51:00 +0000 Received: by gyh20 with SMTP id 20so4533411gyh.36 for ; Sun, 28 Aug 2011 03:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.41.147 with SMTP id o19mr7460826ibe.82.1314528654730; Sun, 28 Aug 2011 03:50:54 -0700 (PDT) Received: by 10.231.147.73 with HTTP; Sun, 28 Aug 2011 03:50:54 -0700 (PDT) In-Reply-To: <4E57C9A3.8000208@ti.com> References: <1309539333-2606-1-git-send-email-per.forlin@linaro.org> <20110826161951.GA26197@n2100.arm.linux.org.uk> <4E57C9A3.8000208@ti.com> Date: Sun, 28 Aug 2011 12:50:54 +0200 Message-ID: Subject: Re: [PATCH v9 00/12] use nonblock mmc requests to minimize latency From: Per Forlin To: Santosh X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110828_065059_262259_86201EAC X-CRM114-Status: GOOD ( 26.09 ) X-Spam-Score: -0.7 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (-0.7 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [209.85.160.177 listed in list.dnswl.org] Cc: Nicolas Pitre , Chris Ball , linaro-dev@lists.linaro.org, Balaji T Krishnamoorthy , Arnd Bergmann , Linus Walleij , linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Kyungmin Park , Russell King - ARM Linux , Sourav Poddar , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-arm-kernel-bounces@lists.infradead.org Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter2.kernel.org [140.211.167.43]); Sun, 28 Aug 2011 10:51:43 +0000 (UTC) X-MIME-Autoconverted: from quoted-printable to 8bit by demeter2.kernel.org id p7SApM7i017330 On 26 August 2011 18:28, Santosh wrote: > + Balaji, > > On Friday 26 August 2011 09:49 PM, Russell King - ARM Linux wrote: >> >> I'm not sure who's responsible for this, but the nonblocking MMC stuff is >> broken on OMAPs HSMMC: >> >> mmcblk0: error -84 transferring data, sector 149201, nr 64, cmd response >> 0x900, card status 0xb00 >> mmcblk0: retrying using single block read >> ------------[ cut here ]------------ >> WARNING: at /home/rmk/git/linux-2.6-rmk/lib/dma-debug.c:811 >> check_unmap+0x1ac/0x764() >> omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory >> it has not allocated [device address=0x0000000080933000] [size=20480 bytes] >> Modules linked in: >> Backtrace: >> [] (dump_backtrace+0x0/0x10c) from [] >> (dump_stack+0x18/0x1c) >>  r7:c1abfcb8 r6:c0186248 r5:c037de51 r4:0000032b >> [] (dump_stack+0x0/0x1c) from [] >> (warn_slowpath_common+0x58/0x70) >> [] (warn_slowpath_common+0x0/0x70) from [] >> (warn_slowpath_fmt+0x38/0x40) >>  r8:c1abfd50 r7:00000000 r6:00005000 r5:00000000 r4:80933000 >> [] (warn_slowpath_fmt+0x0/0x40) from [] >> (check_unmap+0x1ac/0x764) >>  r3:c0367d55 r2:c037e24d >> [] (check_unmap+0x0/0x764) from [] >> (debug_dma_unmap_sg+0x100/0x134) >> [] (debug_dma_unmap_sg+0x0/0x134) from [] >> (dma_unmap_sg+0x24/0x7c) >> [] (dma_unmap_sg+0x0/0x7c) from [] >> (omap_hsmmc_post_req+0x48/0x54) >> [] (omap_hsmmc_post_req+0x0/0x54) from [] >> (mmc_start_req+0x9c/0x128) >>  r4:c1a76000 >> [] (mmc_start_req+0x0/0x128) from [] >> (mmc_blk_issue_rw_rq+0x80/0x460) >>  r8:c1ab5c00 r7:00000001 r6:c1ab5824 r5:c1ab5824 r4:c1ab5c00 >> [] (mmc_blk_issue_rw_rq+0x0/0x460) from [] >> (mmc_blk_issue_rq+0x2cc/0x2fc) >> [] (mmc_blk_issue_rq+0x0/0x2fc) from [] >> (mmc_queue_thread+0xa0/0x104) >> [] (mmc_queue_thread+0x0/0x104) from [] >> (kthread+0x88/0x90) >> [] (kthread+0x0/0x90) from [] (do_exit+0x0/0x618) >>  r7:00000013 r6:c003d9a4 r5:c0054f04 r4:c1a7bc7c >> ---[ end trace 3314ad56daf5d14f ]--- >> >> Luckily thinks continue to work, but clearly releasing DMA mappings which >> drivers don't own is bad news.  Unfortunately, I don't have the bandwidth >> to be able to investigate this at present - well, I could do but then I'd >> have to drop working on the OMAP4 vs generic suspend/resume code and learn >> about something I've no current clue about. >> > Please continue your help on generic suspend. > >> Can someone please investigate and fix whatever is broken. >> > Will find somebody to look at this issue. > I had a look at this and my guess is that the same mapped DMA memory is unmapped twice. First the memory is unmapped in omap_hsmmc_dma_cleanup() due to the mmc error, then later in omap_hsmmc_post_req(). Here is a patch to resolve that. I haven't had the chance to test it yet though. --- drivers/mmc/host/omap_hsmmc.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) } @@ -1576,8 +1577,10 @@ static void omap_hsmmc_post_req(struct mmc_host *mmc, struct mmc_request *mrq, struct mmc_data *data = mrq->data; if (host->use_dma) { - dma_unmap_sg(mmc_dev(host->mmc), data->sg, data->sg_len, - omap_hsmmc_get_dma_dir(host, data)); + if (data->host_cookie) + dma_unmap_sg(mmc_dev(host->mmc), data->sg, + data->sg_len, + omap_hsmmc_get_dma_dir(host, data)); data->host_cookie = 0; I also checked the mmci code for this same issue and mmci doesn't have the same bug. MMCI works fine in 3.1-rc2 even though the code is "wrong". I propose this change. @@ -529,7 +529,7 @@ static void mmci_post_request(struct mmc_host *mmc, struct mmc_request *mrq, if (chan) { if (err) dmaengine_terminate_all(chan); - if (err || data->host_cookie) + if (data->host_cookie) I'll post these patches as soon as I have managed to test them or sooner if I get a tested-by. Regards, Per diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 21e4a79..7f40767 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1011,6 +1011,7 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host *host, int errno) host->data->sg_len, omap_hsmmc_get_dma_dir(host, host->data)); omap_free_dma(dma_ch); + data->host_cookie = 0; } host->data = NULL;