Re: mmci-omap regressions
* ladislav.mi...@seznam.cz [091021 12:15]:
> Hmm, it seems noone is going to fix it for me, so let's move on...
>
> On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> > Hi,
> >
> > * Ladislav Michl [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.0 +0100
> > > +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +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, 0x);
> > > 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:0001127104KiB
> > > 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?
>
> Here is somehow working version. It seems sending init stream multiple times
> is not good idea. Please note I have no clue how is MMC supposed to work
> (except very basic knowledge).
>
> So with the patch (complete patch, see mmc driver fixes I posted earlier
> today)
> below, output looks like:
>
> # modprobe omap
> MMC_POWER_OFF
> MMC dsor: 0
> MMC_POWER_UP
> MMC_POWER_ON
> MMC dsor: 878
> time elapsed: 254us
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> 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)
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 878
> MMC_POWER_ON
> MMC dsor: 803
> mmc0: new MMC card at address 0001
> mmcblk0: mmc0:0001 D0601 122 MiB
> mmcblk0:
> p1
>
> Note, that "command timeout" is still there, but at least it detect card and
> also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
> actually more than 200us.
Good to hear. Can you please resend this too to the mmc list?
Regards,
Tony
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index 5d773b8..0bcd6b0 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -123,15 +123,16 @@ struct mmc_omap_host {
> struct mmc_data * data;
> struct mmc_host * mmc;
> struct device * dev;
> - unsigned char id; /* 16xx chips have 2 MMC blocks */
> struct clk *iclk;
> struct clk *fclk;
> struct resource *mem_res;
> void __iomem*virt_base;
> unsigned intphys_base;
> int irq;
> + unsigned char id; /* 16xx chips have 2 MMC blocks */
> unsigned char bus_mode;
> unsigned char
Re: mmci-omap regressions
Hmm, it seems noone is going to fix it for me, so let's move on...
On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Hi,
>
> * Ladislav Michl [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.0 +0100
> > +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +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, 0x);
> > 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:0001127104KiB
> > 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?
Here is somehow working version. It seems sending init stream multiple times
is not good idea. Please note I have no clue how is MMC supposed to work
(except very basic knowledge).
So with the patch (complete patch, see mmc driver fixes I posted earlier today)
below, output looks like:
# modprobe omap
MMC_POWER_OFF
MMC dsor: 0
MMC_POWER_UP
MMC_POWER_ON
MMC dsor: 878
time elapsed: 254us
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
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)
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 878
MMC_POWER_ON
MMC dsor: 803
mmc0: new MMC card at address 0001
mmcblk0: mmc0:0001 D0601 122 MiB
mmcblk0:
p1
Note, that "command timeout" is still there, but at least it detect card and
also note that "worst case at 400kHz, 80 cycles makes 200 microsecs" took
actually more than 200us.
diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 5d773b8..0bcd6b0 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -123,15 +123,16 @@ struct mmc_omap_host {
struct mmc_data * data;
struct mmc_host * mmc;
struct device * dev;
- unsigned char id; /* 16xx chips have 2 MMC blocks */
struct clk *iclk;
struct clk *fclk;
struct resource *mem_res;
void __iomem*virt_base;
unsigned intphys_base;
int irq;
+ unsigned char id; /* 16xx chips have 2 MMC blocks */
unsigned char bus_mode;
unsigned char hw_bus_mode;
+ unsigned char power_mode;
struct work_struct cmd_abort_work;
unsignedabort:1;
@@ -1233,7 +1234,7 @@ static void mmc_omap_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct mmc_omap_slot *slot = mmc_priv(mmc);
struct mmc_omap_host *host = slot->hos
Re: mmci-omap regressions
2009/1/12 Ladislav Michl :
> 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.0 +0100
> +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +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, 0x);
> did the trick.
Just confirming that I had the same issue on Palm T|E (omap15xx) and
used a similar modification to make it work. This was with 2.6.22 so
very long ago.
Cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmci-omap regressions
Ladislav Michl writes: > 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 [...] > 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 > > I'll happily send any requested debug informations and test any patches I'm getting the same error on Nokia 770. Anything I can do to help? -- Måns Rullgård m...@mansr.com -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmci-omap regressions
On Mon, Jan 12, 2009 at 12:42:43PM +0200, Tony Lindgren wrote:
> Looks like the current git head does goto exit after MMC_POWER_UP before
> you even get to that code.
...and 2.6.22-omap1 version does return at the same place. So patch can be
also shown as
--- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 12:31:52.0 +0100
@@ -974,14 +974,6 @@
* 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) {
- /* Send clock cycles, poll completion */
- OMAP_MMC_WRITE(host, IE, 0);
- OMAP_MMC_WRITE(host, STAT, 0x);
- OMAP_MMC_WRITE(host, CMD, 1 << 7);
- while ((OMAP_MMC_READ(host, STAT) & 1) == 0);
- OMAP_MMC_WRITE(host, STAT, 1);
- }
clk_disable(host->fclk);
}
Sorry for not thinking a bit harder first time. I'll try to figure out how
to make git version working.
ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: mmci-omap regressions
Hi,
* Ladislav Michl [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.0 +0100
> +++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +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, 0x);
> 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:0001127104KiB
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mmci-omap regressions
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.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +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, 0x);
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:0001127104KiB
mmcblk0: p1
while there is no command timeout with 2.6.15-omap2, but at least it works.
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
I'll happily send any requested debug informations and test any patches
Thank you,
ladis
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
