From: Pavel Machek <pavel@suse.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Andrew Morton <akpm@osdl.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>,
kernel list <linux-kernel@vger.kernel.org>,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [patch] pm: fix runtime powermanagement's /sys interface
Date: Fri, 6 Jan 2006 09:59:21 +0100 [thread overview]
Message-ID: <20060106085920.GI3339@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0601051729400.30092-100000@monsoon.he.net>
[-- Attachment #1: Type: text/plain, Size: 2388 bytes --]
On Čt 05-01-06 17:37:30, Patrick Mochel wrote:
>
>
> On Fri, 6 Jan 2006, Pavel Machek wrote:
>
> > On Ät 05-01-06 16:04:07, Patrick Mochel wrote:
>
> > > A better point, and one that would actually be useful, would be to remove
> > > the file altogether. Let Dominik export a power file, with complete
> > > control over the values, for each pcmcia device. Then you never have to
> > > worry about breaking PCMCIA again.
> >
> > Fine with me.
>
> ACK, you beat me to it.
>
> And, appended is a patch to export PM controls for PCI devices. The file
> "pm_possible_states" exports the states a device supports, and "pm_state"
> exports the current state (and provides the interface for entering a
> state).
>
> Eventually, some drivers will want to fix up those values so that it can
> mask of states that it doesn't support, as well as offer possible device-
> specific states.
>
> What's interesting is that with this patch, I can see that two more
> devices on my system support D1 and D2 -- the cardbus controllers, which
> are actually bridges whose PM capabilities aren't exported via
lspci.
> +static ssize_t pm_possible_states_show(struct device * d,
> + struct device_attribute * a,
> + char * buffer)
> +{
> + struct pci_dev * dev = to_pci_dev(d);
> + char * s = buffer;
> +
> + s += sprintf(s, "d0");
> + if (dev->poss_states[PCI_D1])
> + s += sprintf(s, " d1");
> + if (dev->poss_states[PCI_D2])
> + s += sprintf(s, " d2");
> + if (dev->poss_states[PCI_D3hot])
> + s += sprintf(s, " d3");
Could we use same states as rest of code, i.e. "D2" instead of "d2"
and "D3hot" instead of "d3"?
> +static ssize_t pm_state_show(struct device * d, struct device_attribute * a,
> + char * buffer)
Please no space between "struct foo *" and "d".
> + if (state == dev->current_state)
> + return 0;
> +
> + if (dev->poss_states[state])
> + ret = pci_set_power_state(dev, state);
So you just set the PCI power, without any coordination with driver?
How can this work?
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -106,6 +106,7 @@ struct pci_dev {
> this if your device has broken DMA
> or supports 64-bit transfers. */
>
> + u32 poss_states[4];
It is boolean... Can we have int instead of u32?
Pavel
--
Thanks, Sharp!
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@suse.cz>
To: Patrick Mochel <mochel@digitalimplant.org>
Cc: Andrew Morton <akpm@osdl.org>,
Linux-pm mailing list <linux-pm@lists.osdl.org>,
kernel list <linux-kernel@vger.kernel.org>,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [linux-pm] [patch] pm: fix runtime powermanagement's /sys interface
Date: Fri, 6 Jan 2006 09:59:21 +0100 [thread overview]
Message-ID: <20060106085920.GI3339@elf.ucw.cz> (raw)
In-Reply-To: <Pine.LNX.4.50.0601051729400.30092-100000@monsoon.he.net>
On Čt 05-01-06 17:37:30, Patrick Mochel wrote:
>
>
> On Fri, 6 Jan 2006, Pavel Machek wrote:
>
> > On Ät 05-01-06 16:04:07, Patrick Mochel wrote:
>
> > > A better point, and one that would actually be useful, would be to remove
> > > the file altogether. Let Dominik export a power file, with complete
> > > control over the values, for each pcmcia device. Then you never have to
> > > worry about breaking PCMCIA again.
> >
> > Fine with me.
>
> ACK, you beat me to it.
>
> And, appended is a patch to export PM controls for PCI devices. The file
> "pm_possible_states" exports the states a device supports, and "pm_state"
> exports the current state (and provides the interface for entering a
> state).
>
> Eventually, some drivers will want to fix up those values so that it can
> mask of states that it doesn't support, as well as offer possible device-
> specific states.
>
> What's interesting is that with this patch, I can see that two more
> devices on my system support D1 and D2 -- the cardbus controllers, which
> are actually bridges whose PM capabilities aren't exported via
lspci.
> +static ssize_t pm_possible_states_show(struct device * d,
> + struct device_attribute * a,
> + char * buffer)
> +{
> + struct pci_dev * dev = to_pci_dev(d);
> + char * s = buffer;
> +
> + s += sprintf(s, "d0");
> + if (dev->poss_states[PCI_D1])
> + s += sprintf(s, " d1");
> + if (dev->poss_states[PCI_D2])
> + s += sprintf(s, " d2");
> + if (dev->poss_states[PCI_D3hot])
> + s += sprintf(s, " d3");
Could we use same states as rest of code, i.e. "D2" instead of "d2"
and "D3hot" instead of "d3"?
> +static ssize_t pm_state_show(struct device * d, struct device_attribute * a,
> + char * buffer)
Please no space between "struct foo *" and "d".
> + if (state == dev->current_state)
> + return 0;
> +
> + if (dev->poss_states[state])
> + ret = pci_set_power_state(dev, state);
So you just set the PCI power, without any coordination with driver?
How can this work?
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -106,6 +106,7 @@ struct pci_dev {
> this if your device has broken DMA
> or supports 64-bit transfers. */
>
> + u32 poss_states[4];
It is boolean... Can we have int instead of u32?
Pavel
--
Thanks, Sharp!
next prev parent reply other threads:[~2006-01-06 8:59 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-27 21:34 [patch] pm: fix runtime powermanagement's /sys interface Pavel Machek
2005-12-27 21:34 ` Pavel Machek
2005-12-27 21:55 ` Dmitry Torokhov
2005-12-27 21:55 ` [linux-pm] " Dmitry Torokhov
2005-12-27 22:05 ` Pavel Machek
2005-12-27 22:05 ` [linux-pm] " Pavel Machek
2005-12-28 4:22 ` Patrick Mochel
2005-12-28 4:22 ` [linux-pm] " Patrick Mochel
2006-01-04 21:34 ` Pavel Machek
2006-01-04 22:06 ` Alan Stern
2006-01-04 22:06 ` [linux-pm] " Alan Stern
2006-01-04 22:16 ` Pavel Machek
2006-01-05 21:43 ` Patrick Mochel
2006-01-05 21:43 ` [linux-pm] " Patrick Mochel
2006-01-05 22:06 ` Alan Stern
2006-01-05 22:28 ` Pavel Machek
2006-01-05 22:28 ` [linux-pm] " Pavel Machek
2006-01-05 21:42 ` Patrick Mochel
2006-01-05 21:55 ` Pavel Machek
2006-01-05 21:55 ` [linux-pm] " Pavel Machek
2006-01-05 22:13 ` Dominik Brodowski
2006-01-05 22:23 ` Pavel Machek
2006-01-05 22:27 ` Dominik Brodowski
2006-01-05 22:59 ` Pavel Machek
2006-01-05 23:08 ` Pavel Machek
2006-01-05 23:08 ` [linux-pm] " Pavel Machek
2006-01-05 23:46 ` Dominik Brodowski
2006-01-05 23:58 ` Pavel Machek
2006-01-05 23:58 ` [linux-pm] " Pavel Machek
2006-01-06 0:04 ` Patrick Mochel
2006-01-06 0:04 ` [linux-pm] " Patrick Mochel
2006-01-06 0:12 ` Pavel Machek
2006-01-06 0:12 ` [linux-pm] " Pavel Machek
2006-01-06 1:37 ` Patrick Mochel
2006-01-06 1:37 ` [linux-pm] " Patrick Mochel
2006-01-06 8:59 ` Pavel Machek [this message]
2006-01-06 8:59 ` Pavel Machek
2006-01-07 5:47 ` Adam Belay
2006-01-07 5:47 ` [linux-pm] " Adam Belay
2006-01-06 9:00 ` Pavel Machek
2006-01-06 9:00 ` [linux-pm] " Pavel Machek
2006-01-06 15:00 ` Dominik Brodowski
2006-01-06 15:00 ` [linux-pm] " Dominik Brodowski
2006-01-07 5:58 ` Adam Belay
2006-01-07 5:58 ` [linux-pm] " Adam Belay
2006-01-06 15:42 ` Alan Stern
2006-01-06 15:42 ` [linux-pm] " Alan Stern
2006-01-07 0:08 ` Pavel Machek
2006-01-07 0:08 ` [linux-pm] " Pavel Machek
2006-01-07 3:19 ` Alan Stern
2006-01-07 3:19 ` [linux-pm] " Alan Stern
2006-01-07 7:58 ` Adam Belay
2006-01-07 7:58 ` [linux-pm] " Adam Belay
2006-01-07 10:20 ` Pavel Machek
2006-01-07 10:20 ` [linux-pm] " Pavel Machek
2006-01-07 13:06 ` Adam Belay
2006-01-07 13:06 ` [linux-pm] " Adam Belay
2006-01-06 4:17 ` Pavel Machek
2006-01-06 4:17 ` [linux-pm] " Pavel Machek
2006-01-07 7:41 ` Adam Belay
2006-01-07 15:24 ` Alan Stern
2006-01-07 15:24 ` [linux-pm] " Alan Stern
2006-01-06 1:10 ` Dominik Brodowski
2006-01-06 8:53 ` Pavel Machek
2006-01-06 0:38 ` Greg KH
2006-01-06 0:38 ` [linux-pm] " Greg KH
2006-01-06 15:03 ` Dominik Brodowski
2006-01-06 15:03 ` [linux-pm] " Dominik Brodowski
2006-01-06 16:25 ` Kay Sievers
2006-01-06 16:25 ` [linux-pm] " Kay Sievers
2006-01-09 20:10 ` Dominik Brodowski
2006-01-05 22:15 ` Patrick Mochel
2006-01-05 22:44 ` Pavel Machek
2006-01-05 22:44 ` [linux-pm] " Pavel Machek
2006-01-05 23:54 ` Patrick Mochel
2006-01-05 23:54 ` [linux-pm] " Patrick Mochel
2006-01-06 0:07 ` Pavel Machek
2006-01-06 14:34 ` Tom Marshall
2006-01-06 16:20 ` Pavel Machek
2006-01-07 8:36 ` Adam Belay
2006-01-07 8:36 ` [linux-pm] " Adam Belay
2006-01-07 10:25 ` Pavel Machek
2006-01-07 10:25 ` [linux-pm] " Pavel Machek
2006-01-07 12:45 ` Adam Belay
2006-01-07 12:45 ` [linux-pm] " Adam Belay
2006-01-06 4:24 ` Pavel Machek
2006-01-06 4:24 ` [linux-pm] " Pavel Machek
2006-01-13 20:00 ` Takashi Iwai
2006-01-13 20:00 ` [linux-pm] " Takashi Iwai
-- strict thread matches above, loose matches on Subject: below --
2006-01-05 15:16 Scott E. Preece
2006-01-05 22:21 Preece Scott-PREECE
2006-01-05 22:45 ` Pavel Machek
2006-01-06 0:02 ` Patrick Mochel
2006-01-05 22:55 Preece Scott-PREECE
2006-01-05 23:05 ` Pavel Machek
2006-01-06 0:31 Scott E. Preece
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=20060106085920.GI3339@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=linux@dominikbrodowski.net \
--cc=mochel@digitalimplant.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.