From: Lars-Peter Clausen <lars@metafoo.de>
To: Matt Fleming <matt@console-pimps.org>
Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
linux-mmc@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH v2 18/26] MMC: Add JZ4740 mmc driver
Date: Sat, 19 Jun 2010 17:29:35 +0200 [thread overview]
Message-ID: <4C1CE25F.70606@metafoo.de> (raw)
In-Reply-To: <87ocf7ozb2.fsf@linux-g6p1.site>
Hi
Matt Fleming wrote:
> On Sat, 19 Jun 2010 07:08:23 +0200, Lars-Peter Clausen
<lars@metafoo.de> wrote:
>> This patch adds support for the mmc controller on JZ4740 SoCs.
>>
>
> Hey Lars-Peter,
>
> I had a quick look over this patch and it looks OK. Just a few comments.
>
>> +static void jz4740_mmc_timeout(unsigned long data)
>> +{
>> + struct jz4740_mmc_host *host = (struct jz4740_mmc_host *)data;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&host->lock, flags);
>> + if (!host->waiting) {
>> + spin_unlock_irqrestore(&host->lock, flags);
>> + return;
>> + }
>> +
>> + host->waiting = 0;
>> +
>> + spin_unlock_irqrestore(&host->lock, flags);
>> +
>> + host->req->cmd->error = -ETIMEDOUT;
>> + jz4740_mmc_request_done(host);
>> +}
>> +
>
> Taking a spinlock and disabling interrupts seems like too much overhead
> to simply test and clear a bit. Wouldn't it be better to implement this
> with test_and_clear_bit(), which on MIPS will likely be implemented with
> ll/sc instructions? It's particularly important to keep this
> low-overhead since this bit is modified in the interrupt handler.
>
Sounds like a good idea :)
>> +static void jz4740_mmc_request_done(struct jz4740_mmc_host *host)
>> +{
>> + struct mmc_request *req;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&host->lock, flags);
>> + req = host->req;
>> + host->req = NULL;
>> + host->waiting = 0;
>> + spin_unlock_irqrestore(&host->lock, flags);
>> +
>> + if (!unlikely(req))
>> + return;
>> +
>> + mmc_request_done(host->mmc, req);
>> +}
>> +
>
> Am I right in thinking that this spinlock guards against the interrupt
> handler and the timeout function running at the same time? So it's not
> really possible to drop the spinlock from here?
>
Yes, at least that is what it was meant for. But it was there before
the waiting bit and right now I can not construct any code paths that
could lead to jz4740_mmc_request_done from two paths at the same time.
The timer wont call it if the waiting bit is not set and the irq
handler won't wake the threaded irq handler if the waiting bit is not
set. I'll think a bit more about it and eventually drop the spinlock here.
Thanks for your review :)
- Lars
next prev parent reply other threads:[~2010-06-19 15:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-19 5:08 [PATCH v2 00/26] Add support for the Ingenic JZ4740 System-on-a-Chip Lars-Peter Clausen
2010-06-19 5:08 ` [PATCH v2 18/26] MMC: Add JZ4740 mmc driver Lars-Peter Clausen
2010-06-19 14:46 ` Matt Fleming
2010-06-19 15:29 ` Lars-Peter Clausen [this message]
2010-06-28 1:20 ` [PATCH v3] " Lars-Peter Clausen
2010-06-29 20:17 ` Matt Fleming
2010-07-01 15:47 ` Lars-Peter Clausen
2010-06-30 20:55 ` Andrew Morton
2010-07-01 15:45 ` Lars-Peter Clausen
2010-07-12 21:33 ` [PATCH v4] " Lars-Peter Clausen
2010-07-12 21:41 ` Randy Dunlap
2010-07-12 22:07 ` Lars-Peter Clausen
2010-07-12 22:20 ` [PATCH v5] " Lars-Peter Clausen
2010-07-12 22:45 ` Joe Perches
2010-07-12 23:45 ` Lars-Peter Clausen
2010-07-15 21:06 ` [PATCH v6] " Lars-Peter Clausen
2010-07-15 21:16 ` Andrew Morton
2010-07-15 21:37 ` Lars-Peter Clausen
2010-06-20 9:26 ` [PATCH v2 00/26] Add support for the Ingenic JZ4740 System-on-a-Chip Thomas Bogendoerfer
2010-06-21 2:56 ` Xiangfu Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C1CE25F.70606@metafoo.de \
--to=lars@metafoo.de \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-mmc@vger.kernel.org \
--cc=matt@console-pimps.org \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).