On Sat, 19 Jun 2010 07:08:23 +0200, Lars-Peter Clausen <lars@xxxxxxxxxx> 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.
> +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?
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
