From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Carlos Aguiar <carlos.aguiar@indt.org.br>
Cc: linux-kernel@vger.kernel.org, Tony Lindgren <tony@atomide.com>,
Pierre Ossman <drzeus-list@drzeus.cx>
Subject: Re: [RFC] mmc: add OMAP driver
Date: Thu, 16 Feb 2006 15:15:04 +0000 [thread overview]
Message-ID: <20060216151504.GA29443@flint.arm.linux.org.uk> (raw)
In-Reply-To: <43F48BCA.8010608@indt.org.br>
On Thu, Feb 16, 2006 at 10:27:22AM -0400, Carlos Aguiar wrote:
> + /* Any data transfer means adtc type (but that information is not
> + * in command structure, so we flagged it into host struct.)
> + * However, telling bc, bcr and ac apart based on response is
> + * not foolproof:
> + * CMD0 = bc = resp0 CMD15 = ac = resp0
> + * CMD2 = bcr = resp2 CMD10 = ac = resp2
> + *
> + * Resolve to best guess with some exception testing:
> + * resp0 -> bc, except CMD15 = ac
> + * rest are ac, except if opendrain
> + */
> + if (host->data) {
> + cmdtype = OMAP_MMC_CMDTYPE_ADTC;
> + } else if (resptype == 0 && cmd->opcode != 15) {
> + cmdtype = OMAP_MMC_CMDTYPE_BC;
> + } else if (host->bus_mode == MMC_BUSMODE_OPENDRAIN) {
> + cmdtype = OMAP_MMC_CMDTYPE_BCR;
> + } else {
> + cmdtype = OMAP_MMC_CMDTYPE_AC;
> + }
This is no longer necessary - we now supply the command type via
cmd->flags.
> +static void
> +mmc_omap_cmd_done(struct mmc_omap_host *host, struct mmc_command *cmd)
> +{
> + host->cmd = NULL;
> +
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136) {
cmd->resp[3] =
OMAP_MMC_READ(host->base, RSP0) |
(OMAP_MMC_READ(host->base, RSP1) << 16);
cmd->resp[2] =
OMAP_MMC_READ(host->base, RSP2) |
(OMAP_MMC_READ(host->base, RSP3) << 16);
cmd->resp[1] =
OMAP_MMC_READ(host->base, RSP4) |
(OMAP_MMC_READ(host->base, RSP5) << 16);
cmd->resp[0] =
OMAP_MMC_READ(host->base, RSP6) |
(OMAP_MMC_READ(host->base, RSP7) << 16);
} else {
cmd->resp[0] =
OMAP_MMC_READ(host->base, RSP6) |
(OMAP_MMC_READ(host->base, RSP7) << 16);
}
}
would be clearer, and probably more efficient. (gcc isn't really
that good at working out bit patterns from switch statements.)
> + /* Optimize the loop a bit by calculating the register only
> + * once */
> + reg = host->base + OMAP_MMC_REG_DATA;
> + p = host->buffer;
> + n /= 2;
> + if (write) {
> + while (n--)
> + __raw_writew(*p++, reg);
> + } else {
> + while (n-- > 0)
> + *p++ = __raw_readw(reg);
> + }
readsw / writesw would be a far more efficient implementation.
> + host->base = (void __iomem *)pdev->resource[0].start;
This is still very very very very wrong. MMIO resources do not contain
virtual addresses. Casting it to a virtual address like this is insane.
> + mmc_add_host(mmc);
At this point the host becomes live. Is the following initialisation
safe to do after the host has been manipulated to talk to MMC cards?
> +
> + if (host->switch_pin >= 0) {
> + INIT_WORK(&host->switch_work, mmc_omap_switch_handler, host);
> + init_timer(&host->switch_timer);
> + host->switch_timer.function = mmc_omap_switch_timer;
> + host->switch_timer.data = (unsigned long) host;
> + if (omap_request_gpio(host->switch_pin) != 0) {
> + printk(KERN_WARNING "MMC%d: Unable to get GPIO pin for MMC cover switch\n",
> + host->id);
> + host->switch_pin = -1;
> + goto no_switch;
> + }
> +
> + omap_set_gpio_direction(host->switch_pin, 1);
> + set_irq_type(OMAP_GPIO_IRQ(host->switch_pin), IRQT_RISING);
> + ret = request_irq(OMAP_GPIO_IRQ(host->switch_pin),
> + mmc_omap_switch_irq, 0, DRIVER_NAME, host);
Don't use set_irq_type, use request_irq with SA_TRIGGER_RISING please.
> + if (host) {
> + mmc_remove_host(host->mmc);
> + free_irq(host->irq, host);
> +#ifdef CONFIG_I2C
> + mmc_omap_power(host, 0);
> +#endif
Power should be turned off by the MMC layer anyway.
> +#ifdef CONFIG_PM
> +static int mmc_omap_suspend(struct platform_device *pdev, pm_message_t mesg)
> +{
> + int ret = 0;
> + struct mmc_omap_host *host = platform_get_drvdata(pdev);
> +
> + if (host && host->suspended)
> + return 0;
> +
> + if (!irqs_disabled())
> + return -EAGAIN;
IRQs will never be disabled here.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2006-02-16 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-16 14:27 [RFC] mmc: add OMAP driver Carlos Aguiar
2006-02-16 15:15 ` Russell King [this message]
2006-02-16 16:59 ` Russell King
2006-02-24 16:38 ` Carlos Aguiar
2006-02-24 20:48 ` Russell King
[not found] ` <5b5833aa0603030926h5d2c357eoe203a40248796013@mail.gmail.com>
[not found] ` <48b7761d0603030942l53fcd2bbl249297461a54dd3c@mail.gmail.com>
2006-03-03 17:49 ` Carlos Eduardo
2006-03-07 20:53 ` Carlos Aguiar
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=20060216151504.GA29443@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=carlos.aguiar@indt.org.br \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.