From: Tony Lindgren <tony@atomide.com>
To: Ladislav Michl <ladis@linux-mips.org>
Cc: linux-omap@vger.kernel.org
Subject: Re: mmci-omap regressions
Date: Mon, 12 Jan 2009 12:42:43 +0200 [thread overview]
Message-ID: <20090112104242.GA9373@atomide.com> (raw)
In-Reply-To: <20090112091721.GA11921@michl.2n.cz>
Hi,
* Ladislav Michl <ladis@linux-mips.org> [090112 11:19]:
> Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
> my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
> for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
> 2.6.22-omap1 showed that
> --- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.000000000 +0100
> +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.000000000 +0100
> @@ -974,7 +974,7 @@
> * Writing to the CON register twice seems to do the trick. */
> for (i = 0; i < 2; i++)
> OMAP_MMC_WRITE(host, CON, dsor);
> - if (ios->power_mode == MMC_POWER_ON) {
> + if (ios->power_mode == MMC_POWER_UP) {
> /* Send clock cycles, poll completion */
> OMAP_MMC_WRITE(host, IE, 0);
> OMAP_MMC_WRITE(host, STAT, 0xffff);
> did the trick.
>
> With above patch applied to 2.6.22-omap1 I got
> # modprobe omap
> mmci-omap mmci-omap.1: command timeout, CMD 8
> mmcblk0: mmc0:0001 127104KiB
> mmcblk0: p1
> while there is no command timeout with 2.6.15-omap2, but at least it works.
OK, well at least that's a good start on figuring out what has broken
it. It does not seem like the right fix though as the MMC_POWER_UP
should just power up the slot, and clocks should not get turned on
until in MMC_POWER_ON.
> Doing the same modification in current git doesn't help. Moreover removing
> omap.ko and inserting again behaves differently than inserting for first
> time:
> # modprobe omap
> mmci-omap mmci-omap.0: command timeout (CMD8)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD5)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmci-omap mmci-omap.0: command timeout (CMD55)
> mmc0: error -22 whilst initialising MMC card
> # rmmod omap
> # modprobe omap
> mmci-omap: probe of mmci-omap.0 failed with error -16
Looks like the current git head does goto exit after MMC_POWER_UP before
you even get to that code.
> I'll happily send any requested debug informations and test any patches
Can you maybe try to debug by applying your patch and commenting out
the goto exit?
Regards,
Tony
next prev parent reply other threads:[~2009-01-12 10:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-12 9:17 mmci-omap regressions Ladislav Michl
2009-01-12 10:42 ` Tony Lindgren [this message]
2009-01-12 11:35 ` Ladislav Michl
2009-10-21 21:15 ` Ladislav.Michl
2009-10-22 22:01 ` Tony Lindgren
2009-01-20 1:10 ` Måns Rullgård
2009-01-20 9:36 ` andrzej zaborowski
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=20090112104242.GA9373@atomide.com \
--to=tony@atomide.com \
--cc=ladis@linux-mips.org \
--cc=linux-omap@vger.kernel.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