Re: Add INPUT support to toshiba_acpi
Richard Hughes wrote: On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). Do you know how windows does this? Do you have to load a special system-try thing to make the keys work? Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Eike signature.asc Description: This is a digitally signed message part.
Re: [RFC/RFT][PATCH -mm 1/4] PM: Introduce set_target method in pm_ops
On Sun, 2007-06-24 at 22:40 +0200, Rafael J. Wysocki wrote: + * @set_target: Tell the platform which system sleep state is going to be + * entered. The information passed to @set_target should be disregarded + * by the platform as soon as @finish() is executed and if @prepare() + * fails. + * This callback is optional. However, if it is implemented, the + * argument passed to @prepare(), @enter and @finish() must be ignored. I don't understand the point in mandating that then the argument to enter() is to be ignored, why bother? It doesn't look as though we can possibly do anything with the semantics here that would mean the state set by set_target is different to the state passed to enter(), can we? johannes signature.asc Description: This is a digitally signed message part
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Tue, 2007-06-19 at 11:32 +0800, Zhang Rui wrote:
Ok, by inspection (sorry, still dont have much time) - your kernel code
is sending to group 1; i.e
genlmsg_multicast(skb, 0, 1, GFP_ATOMIC);
you need to change that to send to your assigned id, i.e:
genlmsg_multicast(skb, 0, acpi_event_genl_family.id, GFP_ATOMIC);
Oh, that's the problem.
Great, now it works happily. :).
Jamal, thanks for your help!
I wonder if we should hold off on this API until we've worked out the
multicast issue.
Right now we have (mostly by convention afaict) in generic netlink that
everybody has the same group ID as the family ID but that breaks down as
soon as somebody needs more groups than that, which nl80211 will most
likely need.
Hence, the proposal Jamal had was to have a dynamic multicast number
allocator and (if I understood correctly) look up multicast numbers by
family ID/name. This is fairly extensive API/ABI change, but luckily
there are no generic netlink multicast users yet except for the
controller which luckily has the fixed ID 1.
Therefore, if we hold off on this patch until we've written the code for
dynamic multicast groups, we can hardcode the group for controller and
have all others dynamically assigned; if we merge the ACPI events now
we'll have to hardcode the ACPI family ID (and thus multicast group) to
a small number to avoid problems with dynamic multicast groups where the
numbers will be != family ID.
My proposition for the actual dynamic registration interface would be to
add a .groups array to pointers to struct genl_family with that just
being
struct genl_multicast_group {
char *name;
u32 id;
}
(as usual, NULL signifies array termination)
and the controller is responsible for assigning the ID and exporting it
to userspace. name is a per-family field, something like this patch:
---
include/linux/genetlink.h |3 +
include/net/genetlink.h | 15 ++
net/netlink/genetlink.c | 111 ++
3 files changed, 129 insertions(+)
--- wireless-dev.orig/include/net/genetlink.h 2007-06-25 23:56:59.085732308
+0200
+++ wireless-dev/include/net/genetlink.h2007-06-26 00:01:43.935732308
+0200
@@ -5,12 +5,26 @@
#include net/netlink.h
/**
+ * struct genl_multicast_group - generic netlink multicast group
+ * @name: name of the multicast group, names are per-family
+ * @id: multicast group ID, assigned by the core, to use with
+ * genlmsg_multicast().
+ */
+struct genl_multicast_group
+{
+ charname[GENL_NAMSIZ];
+ u32 id;
+};
+
+/**
* struct genl_family - generic netlink family
* @id: protocol family idenfitier
* @hdrsize: length of user specific header in bytes
* @name: name of family
* @version: protocol version
* @maxattr: maximum number of attributes supported
+ * @multicast_groups: multicast groups to be registered
+ * for this family (%NULL-terminated array)
* @attrbuf: buffer to store parsed attributes
* @ops_list: list of all assigned operations
* @family_list: family list
@@ -22,6 +36,7 @@ struct genl_family
charname[GENL_NAMSIZ];
unsigned intversion;
unsigned intmaxattr;
+ struct genl_multicast_group **multicast_groups;
struct nlattr **attrbuf;/* private */
struct list_headops_list; /* private */
struct list_headfamily_list;/* private */
--- wireless-dev.orig/net/netlink/genetlink.c 2007-06-25 23:56:02.805732308
+0200
+++ wireless-dev/net/netlink/genetlink.c2007-06-26 00:39:26.985732308
+0200
@@ -3,6 +3,7 @@
*
* Authors:Jamal Hadi Salim
* Thomas Graf [EMAIL PROTECTED]
+ * Johannes Berg [EMAIL PROTECTED]
*/
#include linux/module.h
@@ -13,6 +14,7 @@
#include linux/string.h
#include linux/skbuff.h
#include linux/mutex.h
+#include linux/bitmap.h
#include net/sock.h
#include net/genetlink.h
@@ -42,6 +44,15 @@ static void genl_unlock(void)
#define GENL_FAM_TAB_MASK (GENL_FAM_TAB_SIZE - 1)
static struct list_head family_ht[GENL_FAM_TAB_SIZE];
+/*
+ * To avoid an allocation at boot of just one unsigned long,
+ * declare it global instead.
+ * Bit 0 (special?) and bit 1 are marked as already used
+ * since group 1 is the controller group.
+ */
+static unsigned long mcast_group_start = 0x3;
+static unsigned long *multicast_groups = mcast_group_start;
+static unsigned long multicast_group_bits = BITS_PER_LONG;
static int genl_ctrl_event(int event, void *data);
@@ -116,6 +127,76 @@ static inline u16 genl_generate_id(void)
return id_gen_idx;
}
+static int genl_register_mcast_group(struct genl_multicast_group *grp)
+{
+ int id = find_first_zero_bit(multicast_groups, multicast_group_bits);
+
+ if (id = multicast_group_bits) {
+ if (multicast_groups == mcast_group_start) {
+
Re: [RFC/RFT][PATCH -mm 4/4] PM: Rework struct platform_suspend_operations
On Sun, 2007-06-24 at 22:44 +0200, Rafael J. Wysocki wrote:
There is no reason why the .prepare() and .finish() methods in 'struct
platform_suspend_operations' should take any arguments, since architectures
don't use these methods' argument in any practically meaningful way (ie.
either
the target system sleep state is conveyed to the platform by .set_target(), or
there is only one suspend state supported and it is indicated to the PM core
by
.valid(), or .prepare() and .finish() aren't defined at all). There also is
no reason why .finish() should return any result.
Nice cleanups, I'd wanted to do them when I was doing all that pm_ops
stuff but then didn't get around. Good stuff.
--- linux-2.6.22-rc5.orig/arch/powerpc/platforms/52xx/mpc52xx_pm.c
2007-06-24 20:45:21.0 +0200
+++ linux-2.6.22-rc5/arch/powerpc/platforms/52xx/mpc52xx_pm.c 2007-06-24
21:07:41.0 +0200
-int mpc52xx_pm_prepare(suspend_state_t state)
+static int mpc52xx_pm_prepare(void)
{
- if (state != PM_SUSPEND_STANDBY)
- return -EINVAL;
-
Hm. I thought I'd told them to leave that out before it went in. Oh
well.
johannes
signature.asc
Description: This is a digitally signed message part
Re: Add INPUT support to toshiba_acpi
On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote: Richard Hughes wrote: On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote: None of the above keys generated a key event. Neither does Brightness down, but it still works. Brightness up generates an event and works. Kpowersave tells me it can't do brightness switching in software (which works in WinXtraPain). Yes, I need a special process running for this. Would it be of some use if I take a look with IRPtracker on it or is that all you need to know? Yes, although this is out of my area or expertise, sorry. Richard. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT][PATCH -mm 1/4] PM: Introduce set_target method in pm_ops
On Monday, 25 June 2007 23:28, Johannes Berg wrote: On Sun, 2007-06-24 at 22:40 +0200, Rafael J. Wysocki wrote: + * @set_target: Tell the platform which system sleep state is going to be + * entered. The information passed to @set_target should be disregarded + * by the platform as soon as @finish() is executed and if @prepare() + * fails. + * This callback is optional. However, if it is implemented, the + * argument passed to @prepare(), @enter and @finish() must be ignored. I don't understand the point in mandating that then the argument to enter() is to be ignored, why bother? It doesn't look as though we can possibly do anything with the semantics here that would mean the state set by set_target is different to the state passed to enter(), can we? In principle we can't, but I think that it should be either, or. Either the platform implements set_target() and uses the value provided by it, or it uses the argument passed to the other functions. Alternatively, I could write that the argument passed to .enter() etc. is guaranteed to be the same as the one passed to .set_target(), but I didn't want to say that. :-) Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT][PATCH -mm 3/8] ACPI: Add acpi_pm_device_sleep_state helper routine (updated)
[The previous version wouldn't work correctly.]
---
From: Shaohua Li [EMAIL PROTECTED], Rafael J. Wysocki [EMAIL PROTECTED]
Based on the David Brownell's patch at
http://marc.info/?l=linux-acpim=117873972806360w=2
Add a helper routine returning the lowest power (highest number) ACPI device
power state that given device can be in while the system is in the sleep state
indicated by acpi_target_sleep_state .
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
---
drivers/acpi/sleep/main.c | 51 ++
include/acpi/acpi_bus.h |2 +
2 files changed, 53 insertions(+)
Index: linux-2.6.22-rc6/drivers/acpi/sleep/main.c
===
--- linux-2.6.22-rc6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.22-rc6/drivers/acpi/sleep/main.c
@@ -262,6 +262,57 @@ static struct hibernation_ops acpi_hiber
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
+/**
+ * acpi_pm_device_sleep_state - return the lowest power (highest number)
+ * ACPI device power state given device can be
+ * in while the system is in the sleep state
+ * indicated by %acpi_target_sleep_state
+ * @handle: Represents the device the state is evaluated for
+ */
+
+int acpi_pm_device_sleep_state(acpi_handle handle)
+{
+ char acpi_method[] = _SxD;
+ unsigned long d_min, d_max;
+ struct acpi_device *dev;
+
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, adev)))
+ printk(KERN_ERR ACPI handle has no context!\n);
+ return -ENODEV;
+ }
+ acpi_method[2] = '0' + acpi_target_sleep_state;
+ /*
+* If the sleep state is S0, we will return D3, but if the device has
+* _S0W, we will use the value from _S0W
+*/
+ d_min = ACPI_STATE_D3;
+ d_max = ACPI_STATE_D3;
+ /*
+* If present, _SxD methods give the minimum D-state we may use
+* for each S-state ... with lowest latency state switching.
+*
+* We rely on acpi_evaluate_integer() not clobbering the integer
+* provided -- that's our fault recovery, we ignore retval.
+*/
+ if (acpi_target_sleep_state ACPI_STATE_S0)
+ acpi_evaluate_integer(handle, acpi_method, NULL, d_min);
+
+ /*
+* If _PRW says we can wake from the upcoming system state, the _SxD
+* value can wake ... and we'll assume a wakeup-aware driver. If _SxW
+* methods exist (ACPI 3.x), they give the lowest power D-state that
+* can also wake the system. _S0W can be valid.
+*/
+ if (acpi_target_sleep_state == ACPI_STATE_S0 ||
+ (dev-wakeup.state.enabled
+dev-wakeup.sleep_state = acpi_target_sleep_state)) {
+ d_max = d_min;
+ acpi_method[3] = 'W';
+ acpi_evaluate_integer(handle, acpi_method, NULL, d_max);
+ }
+ return d_max;
+}
+
/*
* Toshiba fails to preserve interrupts over S1, reinitialization
* of 8259 is needed after S1 resume.
Index: linux-2.6.22-rc6/include/acpi/acpi_bus.h
===
--- linux-2.6.22-rc6.orig/include/acpi/acpi_bus.h
+++ linux-2.6.22-rc6/include/acpi/acpi_bus.h
@@ -364,6 +364,8 @@ acpi_handle acpi_get_child(acpi_handle,
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)-archdata.acpi_handle))
+int acpi_pm_device_sleep_state(acpi_handle handle);
+
#endif /* CONFIG_ACPI */
#endif /*__ACPI_BUS_H__*/
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/RFT][PATCH -mm 3/8] ACPI: Add acpi_pm_device_sleep_state helper routine (updated 2x)
[The previous version didn't compile. Sorry for the mess.]
---
From: Shaohua Li [EMAIL PROTECTED], Rafael J. Wysocki [EMAIL PROTECTED]
Based on David Brownell's patch at
http://marc.info/?l=linux-acpim=117873972806360w=2
Add a helper routine returning the lowest power (highest number) ACPI device
power state that given device can be in while the system is in the sleep state
indicated by acpi_target_sleep_state .
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
drivers/acpi/sleep/main.c | 51 ++
include/acpi/acpi_bus.h |2 +
2 files changed, 53 insertions(+)
Index: linux-2.6.22-rc6/drivers/acpi/sleep/main.c
===
--- linux-2.6.22-rc6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.22-rc6/drivers/acpi/sleep/main.c
@@ -262,6 +262,57 @@ static struct hibernation_ops acpi_hiber
};
#endif /* CONFIG_SOFTWARE_SUSPEND */
+/**
+ * acpi_pm_device_sleep_state - return the lowest power (highest number)
+ * ACPI device power state given device can be
+ * in while the system is in the sleep state
+ * indicated by %acpi_target_sleep_state
+ * @handle: Represents the device the state is evaluated for
+ */
+
+int acpi_pm_device_sleep_state(acpi_handle handle)
+{
+ char acpi_method[] = _SxD;
+ unsigned long d_min, d_max;
+ struct acpi_device *dev;
+
+ if (!handle || ACPI_FAILURE(acpi_bus_get_device(handle, dev))) {
+ printk(KERN_ERR ACPI handle has no context!\n);
+ return -ENODEV;
+ }
+ acpi_method[2] = '0' + acpi_target_sleep_state;
+ /*
+* If the sleep state is S0, we will return D3, but if the device has
+* _S0W, we will use the value from _S0W
+*/
+ d_min = ACPI_STATE_D3;
+ d_max = ACPI_STATE_D3;
+ /*
+* If present, _SxD methods give the minimum D-state we may use
+* for each S-state ... with lowest latency state switching.
+*
+* We rely on acpi_evaluate_integer() not clobbering the integer
+* provided -- that's our fault recovery, we ignore retval.
+*/
+ if (acpi_target_sleep_state ACPI_STATE_S0)
+ acpi_evaluate_integer(handle, acpi_method, NULL, d_min);
+
+ /*
+* If _PRW says we can wake from the upcoming system state, the _SxD
+* value can wake ... and we'll assume a wakeup-aware driver. If _SxW
+* methods exist (ACPI 3.x), they give the lowest power D-state that
+* can also wake the system. _S0W can be valid.
+*/
+ if (acpi_target_sleep_state == ACPI_STATE_S0 ||
+ (dev-wakeup.state.enabled
+dev-wakeup.sleep_state = acpi_target_sleep_state)) {
+ d_max = d_min;
+ acpi_method[3] = 'W';
+ acpi_evaluate_integer(handle, acpi_method, NULL, d_max);
+ }
+ return d_max;
+}
+
/*
* Toshiba fails to preserve interrupts over S1, reinitialization
* of 8259 is needed after S1 resume.
Index: linux-2.6.22-rc6/include/acpi/acpi_bus.h
===
--- linux-2.6.22-rc6.orig/include/acpi/acpi_bus.h
+++ linux-2.6.22-rc6/include/acpi/acpi_bus.h
@@ -364,6 +364,8 @@ acpi_handle acpi_get_child(acpi_handle,
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int, unsigned int);
#define DEVICE_ACPI_HANDLE(dev) ((acpi_handle)((dev)-archdata.acpi_handle))
+int acpi_pm_device_sleep_state(acpi_handle handle);
+
#endif /* CONFIG_ACPI */
#endif /*__ACPI_BUS_H__*/
-
To unsubscribe from this list: send the line unsubscribe linux-acpi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink
On Tue, 2007-06-26 at 09:33 -0400, jamal wrote: On Tue, 2007-26-06 at 00:40 +0200, Johannes Berg wrote: I wonder if we should hold off on this API until we've worked out the multicast issue. I think we can fix all the code in one shot later. Yes, we could fix the code in the kernel, but since the family ID is dynamically assigned and I'm trying to decouple the multicast group ID from the family ID that would break userspace relying on family==multicast group unless we somehow reserved the family ID number ACPI got to make sure that ACPI gets the same multicast group ID. Combined with the fact that ACPI might be modular and get into generic netlink late in the game this seems non-trivial; also I think it's not necessary since holding off on this ACPI genetlink multicast user (which is the first besides the controller!) until we've worked out the patch shouldn't hurt much. I just glanced at your patch but i have to run out, i will stare at it later - seems to be in the right direction. Thanks. johannes signature.asc Description: This is a digitally signed message part
Re: [RFC/RFT][PATCH -mm 1/4] PM: Introduce set_target method in pm_ops
On Tuesday 26 June 2007, Rafael J. Wysocki wrote: Alternatively, I could write that the argument passed to .enter() etc. is guaranteed to be the same as the one passed to .set_target(), but I didn't want to say that. :-) Why not? So long as enter() takes an argument, that seems to me exactly what it should guarantee. Although that argument should vanish; any platform that differentiates what it does based on that parameter can just be required to provide a set_target() method. - Dave - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT][PATCH -mm 6/8] PM: Rework struct platform_suspend_operations
Hi! There is no reason why the .prepare() and .finish() methods in 'struct platform_suspend_operations' should take any arguments, since architectures don't use these methods' argument in any practically meaningful way (ie. either the target system sleep state is conveyed to the platform by .set_target(), or there is only one suspend state supported and it is indicated to the PM core by .valid(), or .prepare() and .finish() aren't defined at all). There also is no reason why .finish() should return any result. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] ACK. (Maybe you should not in changelog that this changes absolutely no behaviour; it is not immediately obvious). -- (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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT][PATCH -mm 1/4] PM: Introduce set_target method in pm_ops
On Mon 2007-06-25 23:28:06, Johannes Berg wrote: On Sun, 2007-06-24 at 22:40 +0200, Rafael J. Wysocki wrote: + * @set_target: Tell the platform which system sleep state is going to be + * entered. The information passed to @set_target should be disregarded + * by the platform as soon as @finish() is executed and if @prepare() + * fails. + * This callback is optional. However, if it is implemented, the + * argument passed to @prepare(), @enter and @finish() must be ignored. I don't understand the point in mandating that then the argument to enter() is to be ignored, why bother? It doesn't look as though we can possibly do anything with the semantics here that would mean the state set by set_target is different to the state passed to enter(), can we? That's what 4/4 does, AFAICT. -- (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-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] remove leftover documentation of acpi_generic_hotkey
This looks leftover text in the kernel parameter in documentation. Signed-off-by: Stephen Hemminger [EMAIL PROTECTED] --- a/Documentation/kernel-parameters.txt 2007-06-26 16:46:57.0 -0400 +++ b/Documentation/kernel-parameters.txt 2007-06-26 16:47:07.0 -0400 @@ -223,11 +223,6 @@ and is between 256 and 4096 characters. acpi_fake_ecdt [HW,ACPI] Workaround failure due to BIOS lacking ECDT - acpi_generic_hotkey [HW,ACPI] - Allow consolidated generic hotkey driver to - override platform specific driver. - See also Documentation/acpi-hotkey.txt. - acpi_pm_good[IA-32,X86-64] Override the pmtimer bug detection: force the kernel to assume that this machine's pmtimer latches its value - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
