Re: [mmc] incorrect behavior on resume
> 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 http://answers.yahoo.com/dir/?link=list=396545367 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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
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 QA. http://answers.yahoo.com/dir/?link=listsid=396545367 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] 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
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 kernel2.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 [EMAIL PROTECTED] 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
--- Pavel Machek <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
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 maintainerhttp://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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[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:
0xe624, 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:
0xe624, 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:
0xe624, 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:
0xe624, 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 = 33, 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 = 33, 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 = 33, 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 = 33, 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);
[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:
0xe624, 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:
0xe624, 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:
0xe624, 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:
0xe624, 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 = 33, 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 = 33, 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 = 33, 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 = 33, 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);
Re: [mmc] incorrect behavior on resume
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 maintainerhttp://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 [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] 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
--- Pavel Machek [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
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 kernel2.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
