Query regarding behavior of PCMCIA devices with respect to suspend and resume

Query regarding behavior of PCMCIA devices with respect to suspend and resume

[kaustav.majumdar]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Hi all,

I am new to linux power management.... I had seen some PCMCIA client
drivers, where in the event handler for events CARD_SUSPEND and
CARD_RESUME nothing generic had been done but those events ultimately
causes release and get configuration only.....
So does that mean the expected behavior from any PCMCIA device in case
of suspend/resume activity is to release its configurations on
suspension and getting new configuration without actually resuming the
task the device was performing at the time of suspension???
I am looking forward to any kind of suggestion regarding the doubt. And
please reply in my mail id too as I am not subscribed to the list.
Thank you, 
Regards,
Kaustav Majumdar


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Query regarding behavior of PCMCIA devices with respect to suspend and resume

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

Hi,

On Tue, Jan 17, 2006 at 02:12:20PM +0530, kaustav.majumdar@wipro.com wrote:
> I am new to linux power management.... I had seen some PCMCIA client
> drivers, where in the event handler for events CARD_SUSPEND and
> CARD_RESUME nothing generic had been done but those events ultimately
> causes release and get configuration only.....

Exactly; and that's why this even gets moved into the upper layer for
2.6.17:
http://kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-2.6.git;a=commit;h=66b91eb48d18d4781bddcf8f0ac872e2405903fc

> So does that mean the expected behavior from any PCMCIA device in case
> of suspend/resume activity is to release its configurations on
> suspension and getting new configuration without actually resuming the
> task the device was performing at the time of suspension???

Well, most PCMCIA drivers are "dumb" in this regard -- but, for example, the
net drivers do stop the queue and restart it on suspend and resume. To do it
properly, you do need to stop all activity in the .suspend() callback and
continue processing it in or after .resume()

	Dominik

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Query regarding behavior of PCMCIA devices with respect to suspend and resume

[kaustav.majumdar]

[-- Attachment #1: Type: text/plain, Size: 1743 bytes --]

Hi,

Thank you for the reply. 
If in a PCMCIA device, there will be a USB port, then suspend/resume can
be or will be handled by controller for that USB port. But I am not sure
whether in that case, the PCMCIA client driver should support the HCD or
not and if yes then in what way?

Thank you,
Regards,
Kaustav Majumdar


-----Original Message-----
From: Dominik Brodowski [mailto:linux@dominikbrodowski.net] 
Sent: Tuesday, January 17, 2006 2:28 PM
To: Kaustav Majumdar (WT01 - Semiconductors & Consumer Electronics)
Cc: linux-pm@lists.osdl.org
Subject: Re: [linux-pm] Query regarding behavior of PCMCIA devices with
respect to suspend and resume

Hi,

On Tue, Jan 17, 2006 at 02:12:20PM +0530, kaustav.majumdar@wipro.com
wrote:
> I am new to linux power management.... I had seen some PCMCIA client
> drivers, where in the event handler for events CARD_SUSPEND and
> CARD_RESUME nothing generic had been done but those events ultimately
> causes release and get configuration only.....

Exactly; and that's why this even gets moved into the upper layer for
2.6.17:
http://kernel.org/git/?p=linux/kernel/git/brodo/pcmcia-2.6.git;a=commit;
h=66b91eb48d18d4781bddcf8f0ac872e2405903fc

> So does that mean the expected behavior from any PCMCIA device in case
> of suspend/resume activity is to release its configurations on
> suspension and getting new configuration without actually resuming the
> task the device was performing at the time of suspension???

Well, most PCMCIA drivers are "dumb" in this regard -- but, for example,
the
net drivers do stop the queue and restart it on suspend and resume. To
do it
properly, you do need to stop all activity in the .suspend() callback
and
continue processing it in or after .resume()

	Dominik


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Query regarding behavior of PCMCIA devices with respect to suspend and resume

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

Hi,

On Tue, Jan 17, 2006 at 06:49:11PM +0530, kaustav.majumdar@wipro.com wrote:
> If in a PCMCIA device, there will be a USB port, then suspend/resume can
> be or will be handled by controller for that USB port.

If that driver supports a suspend and resume method, then yes, it will be
handled automatically as the PCMCIA subsystem is fully integrated into the
Linux kernel device model infrastructuire.

> But I am not sure
> whether in that case, the PCMCIA client driver should support the HCD or
> not and if yes then in what way?

What do you mean with this? What do you mean with "HCD"?

	Domninik

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Query regarding behavior of PCMCIA devices with respect to suspend and resume

[kaustav.majumdar]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

Hi
What I want to say is that if we will be doing a large file transfer
using the USB port of the PCMCIA device, then after suspend when we will
resume whether the file transfer will be resumed or it will be starting
all over again?
Let us suppose that the controller for the USB port has the capability
to resume the transfer. But the PCMCIA client driver will release the
configuration on suspension and get a new configuration on resumption
(as in a number of PCMCIA client driver). As the controller of the USB
port will be using the resources allocated by the PCMCIA client driver
and as per my understanding, during the new configuration the resources
can be allocated anywhere in the io space (no guarantee of getting
mapped in the same region of io space where it was before suspension), I
think it will be troublesome to handle suspend/resume in the controller
for the USB port if we will do nothing extra inside PCMCIA client
driver.
And sorry for using the term HCD. Actually I was trying to say the
controller for the USB port.
Thank you,
Regards,
Kaustav Majumdar

-----Original Message-----
From: Dominik Brodowski [mailto:linux@dominikbrodowski.net] 
Sent: Wednesday, January 18, 2006 1:11 AM
To: Kaustav Majumdar (WT01 - Semiconductors & Consumer Electronics)
Cc: linux-pm@lists.osdl.org
Subject: Re: [linux-pm] Query regarding behavior of PCMCIA devices with
respect to suspend and resume

Hi,

On Tue, Jan 17, 2006 at 06:49:11PM +0530, kaustav.majumdar@wipro.com
wrote:
> If in a PCMCIA device, there will be a USB port, then suspend/resume
can
> be or will be handled by controller for that USB port.

If that driver supports a suspend and resume method, then yes, it will
be
handled automatically as the PCMCIA subsystem is fully integrated into
the
Linux kernel device model infrastructuire.

> But I am not sure
> whether in that case, the PCMCIA client driver should support the HCD
or
> not and if yes then in what way?

What do you mean with this? What do you mean with "HCD"?

	Domninik


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

RE: Query regarding behavior of PCMCIA devices with respect to suspend and resume

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1303 bytes --]

On Wed, 18 Jan 2006 kaustav.majumdar@wipro.com wrote:

> Hi
> What I want to say is that if we will be doing a large file transfer
> using the USB port of the PCMCIA device, then after suspend when we will
> resume whether the file transfer will be resumed or it will be starting
> all over again?
> Let us suppose that the controller for the USB port has the capability
> to resume the transfer. But the PCMCIA client driver will release the
> configuration on suspension and get a new configuration on resumption
> (as in a number of PCMCIA client driver). As the controller of the USB
> port will be using the resources allocated by the PCMCIA client driver
> and as per my understanding, during the new configuration the resources
> can be allocated anywhere in the io space (no guarantee of getting
> mapped in the same region of io space where it was before suspension), I
> think it will be troublesome to handle suspend/resume in the controller
> for the USB port if we will do nothing extra inside PCMCIA client
> driver.

This question should be posted on linux-usb-devel, since it's really 
asking about the behavior of USB host controller drivers.

Right now, the only USB host controller with a PCMCIA driver is sl811,
so you should also CC: the author of the sl811_cs.c file.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]