Mailing List Archive

[mmc] incorrect behavior on resume
And today: yet another problem with mmc.
It so happens that after resume mmc layer issues requests to the device before mmc_resume_host is
called at all. Moreover, this prevents the machine from resuming, unless worked around, because
software timer does not work at this stage of the resume and interrupts may not be delivered (if
card was removed, for example).
And here are some logs (condition: card is present when machine is suspended and removed before it
is resumed).
Normally, only this is seen in the log:
---------
Feb 18 01:42:09 mortug usbdev3.1_ep00: PM: resume from 0, parent usb3 still 2
Feb 18 01:42:09 mortug usbdev3.1_ep81: PM: resume from 0, parent 3-0:1.0 still 2
Feb 18 01:42:09 mortug tifm_sd0:3 : controller failed to reset
Feb 18 01:42:09 mortug tifm_sd tifm_sd0:3: resume initialize -19
Feb 18 01:42:09 mortug mmcblk0: unable to set block size to 512: 1
---------
Here, the controller failed to reset because card disappeared, so mmc_resume_host will not be
called - however mmc layer already complains that it can not set the block size. To get a better
log, I commented out the mmc_remove_host and left the card in place:

--------
Feb 18 01:02:58 mortug usbdev3.1_ep00: PM: resume from 0, parent usb3 still 2
Feb 18 01:02:58 mortug usbdev3.1_ep81: PM: resume from 0, parent 3-0:1.0 still 2
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: resume initialize 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x7, arg: 0xe6240000, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x7, arg: 0xe6240000, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x7, arg: 0xe6240000, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x7, arg: 0xe6240000, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: executing opcode 0x10, arg: 0x200, mask: 0x2140
Feb 18 01:02:58 mortug tifm_sd tifm_sd0:3: host event: host_status 80, flags 0
Feb 18 01:02:58 mortug mmcblk0: unable to set block size to 512: 1
-----

It appears to me that mmc_block resumes and starts issuing requests all by itself, which is
incorrect.

For reference - correct resume sequence (card remains in place, mmc_resume_host called):

------
Feb 18 01:41:34 mortug usbdev3.1_ep00: PM: resume from 0, parent usb3 still 2
Feb 18 01:41:34 mortug usbdev3.1_ep81: PM: resume from 0, parent 3-0:1.0 still 2
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: resume initialize 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: ios: clock = 0, vdd = 15, bus_mode = 1, chip_select =
0, power_mode = 1, bus_width = 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: ios: clock = 333333, vdd = 15, bus_mode = 1,
chip_select = 0, power_mode = 2, bus_width = 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: ios: clock = 333333, vdd = 15, bus_mode = 1,
chip_select = 1, power_mode = 2, bus_width = 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: executing opcode 0x0, arg: 0x0, mask: 0x40
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: host event: host_status 1, flags 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: ios: clock = 333333, vdd = 15, bus_mode = 1,
chip_select = 0, power_mode = 2, bus_width = 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: executing opcode 0x37, arg: 0x0, mask: 0x2140
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: host event: host_status 1, flags 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: executing opcode 0x29, arg: 0x0, mask: 0x1340
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: host event: host_status 1001, flags 0
Feb 18 01:41:34 mortug tifm_sd tifm_sd0:3: ios: clock = 333333, vdd = 14, bus_mode = 1,
chip_select = 0, power_mode = 2, bus_width = 0
-------

My really simple resume function:
-------
static int tifm_sd_resume(struct tifm_dev *sock)
{
struct mmc_host *mmc = tifm_get_drvdata(sock);
struct tifm_sd *host = mmc_priv(mmc);
int rc;

rc = tifm_sd_initialize_host(host);
dev_dbg(&sock->dev, "resume initialize %d\n", rc);

if (!rc) {
host->eject = 0;
rc = mmc_resume_host(mmc);
}

return rc;
}





____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume [ In reply to ]
Alex Dubov wrote:
> And today: yet another problem with mmc.
> It so happens that after resume mmc layer issues requests to the device before mmc_resume_host is
> called at all. Moreover, this prevents the machine from resuming, unless worked around, because
> software timer does not work at this stage of the resume and interrupts may not be delivered (if
> card was removed, for example).

Now this sounds incredibly broken. A child device should never be resumed before
its parent. Pavel, can you comment?

Rgds
--
-- Pierre Ossman

Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume [ In reply to ]
On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> Alex Dubov wrote:
> > And today: yet another problem with mmc.
> > It so happens that after resume mmc layer issues requests to the device before mmc_resume_host is
> > called at all. Moreover, this prevents the machine from resuming, unless worked around, because
> > software timer does not work at this stage of the resume and interrupts may not be delivered (if
> > card was removed, for example).
>
> Now this sounds incredibly broken. A child device should never be resumed before
> its parent. Pavel, can you comment?

No, child devices should not be resumed before their parents. Is it
true child?

What bus is mmc on? Timer should be resumed fairly early...?

Can you confirm that rmmod/insmod of mmc around suspend fixes the issue?

But this is greg's area.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume [ In reply to ]
--- Pavel Machek <pavel@ucw.cz> wrote:

> On Sun 2007-02-18 00:35:33, Pierre Ossman wrote:
> > Alex Dubov wrote:
> > > And today: yet another problem with mmc.
> > > It so happens that after resume mmc layer issues requests to the device before
> mmc_resume_host is
> > > called at all. Moreover, this prevents the machine from resuming, unless worked around,
> because
> > > software timer does not work at this stage of the resume and interrupts may not be delivered
> (if
> > > card was removed, for example).
> >
> > Now this sounds incredibly broken. A child device should never be resumed before
> > its parent. Pavel, can you comment?
>
> No, child devices should not be resumed before their parents. Is it
> true child?
>
> What bus is mmc on? Timer should be resumed fairly early...?
>
> Can you confirm that rmmod/insmod of mmc around suspend fixes the issue?
>
> But this is greg's area.
It sure does - if I'll do "rmmod mmc" I'd be forced to remove my driver as well (symbol
dependency) and the problem will magically disappear.

The problem here is that mmc_block's device is a child of real device (tifm_dev here), so it gets
resumed right after it. However, it correct functioning depends on mmc_core, which must be
manually resumed (mmc_resume_host). Therefore, I think this is purely mmc's problem.




____________________________________________________________________________________
Bored stiff? Loosen up...
Download and play hundreds of games for free on Yahoo! Games.
http://games.yahoo.com/games/front
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume [ In reply to ]
On Sat, Feb 17, 2007 at 05:46:35PM -0800, Alex Dubov wrote:
> The problem here is that mmc_block's device is a child of real device
> (tifm_dev here), so it gets resumed right after it.

The host driver is supposed to call mmc_resume_host from it's resume
callback. This should be called before the child's resume callback.

> However, it correct functioning depends on mmc_core, which must be
> manually resumed (mmc_resume_host). Therefore, I think this is
> purely mmc's problem.

I don't see that - as I say above, the correct sequence is:

- host device resume
- calls mmc_resume_host()
- child's device resume (mmc_blk_resume)
- mmc_queue_resume()

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [mmc] incorrect behavior on resume [ In reply to ]
> I don't see that - as I say above, the correct sequence is:
>
> - host device resume
> - calls mmc_resume_host()
> - child's device resume (mmc_blk_resume)
> - mmc_queue_resume()
>
Of course, I understand that this is a correct sequence. It simply was not obvious to me that host
will issue requests even if mmc_resume_host is not called.

I'm trying to implement a hotplugable host, so I assumed that if host was removed during the
suspended state there's no need to resume it.




____________________________________________________________________________________
Food fight? Enjoy some healthy debate
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/