Re: notify userland about C-state changes

2012-10-03 Thread Andriy Gapon
on 02/10/2012 20:18 Sean Bruno said the following:
 
 The following patch adds only per-CPU notifications.

 acpi_cpu: explicitly notify userland about c-state changes

 diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
 index 82e204a..15201f9 100644
 --- a/sys/dev/acpica/acpi_cpu.c
 +++ b/sys/dev/acpica/acpi_cpu.c
 @@ -1054,6 +1054,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void 
 *context)
  ACPI_SERIAL_BEGIN(cpu);
  acpi_cpu_set_cx_lowest(sc);
  ACPI_SERIAL_END(cpu);
 +
 +acpi_UserNotify(PROCESSOR, sc-cpu_handle, notify);
  }

  static int

 
 So quick question, does this happen a lot on a system with a sporadic
 workload?  Does this introduce overhead to the system to service the
 notification requests?

I am not sure who can answer this question.  It is up to ACPI platform to decide
when it changes _available C-states_.  OS doesn't have control over that.

P.S.  I hope you haven't confused this notification for a notification about
_current_ C-state changing.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: notify userland about C-state changes

2012-10-03 Thread Sean Bruno
On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote:
  
  So quick question, does this happen a lot on a system with a
 sporadic
  workload?  Does this introduce overhead to the system to service the
  notification requests?
 
 I am not sure who can answer this question.  It is up to ACPI platform
 to decide
 when it changes _available C-states_.  OS doesn't have control over
 that.
 
Hrm ... what changes to the machine would make this happen while the
machine is running?  things like the switching from battery to line
power?


 P.S.  I hope you haven't confused this notification for a notification
 about
 _current_ C-state changing. 

I did have it confused.  Thanks for putting this note in.

Sean

___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


Re: notify userland about C-state changes

2012-10-03 Thread Andriy Gapon
on 03/10/2012 19:21 Sean Bruno said the following:
 On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote:

 So quick question, does this happen a lot on a system with a
 sporadic
 workload?  Does this introduce overhead to the system to service the
 notification requests?

 I am not sure who can answer this question.  It is up to ACPI platform
 to decide
 when it changes _available C-states_.  OS doesn't have control over
 that.

 Hrm ... what changes to the machine would make this happen while the
 machine is running?  things like the switching from battery to line
 power?

Yes.  Or something else [?] of similar nature/effect.

 P.S.  I hope you haven't confused this notification for a notification
 about
 _current_ C-state changing. 
 
 I did have it confused.  Thanks for putting this note in.

OK :-)

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org


acpi_wmi: move wmi_info_list into sc

2012-10-03 Thread Andriy Gapon

Please take a look at the following patch and a commit message that explains it.
I observed the problem on a system with acpi_wmi instances where one instance
overrode GUID list from the other.

commit f1f4109b1588872906ed56086e2680ac1af96268
Author: Andriy Gapon a...@icyb.net.ua
Date:   Thu Sep 27 13:48:18 2012 +0300

acpi_wmi: move wmi_info_list into sc

different instances of acpi_wmi couldn't properly share it and in fact
there was no reason to do that

diff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 5a37979..5927ee1 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -74,6 +74,7 @@ struct acpi_wmi_softc {
struct sbuf wmistat_sbuf;   /* sbuf for /dev/wmistat output */
pid_t   wmistat_open_pid; /* pid operating on /dev/wmistat */
int wmistat_bufptr; /* /dev/wmistat ptr to buffer position 
*/
+   TAILQ_HEAD(wmi_info_list_head, wmi_info) wmi_info_list;
 };

 /*
@@ -105,8 +106,6 @@ struct wmi_info {
void*event_handler_user_data; /* ev handler cookie  
*/
 };

-TAILQ_HEAD(wmi_info_list_head, wmi_info)
-wmi_info_list = TAILQ_HEAD_INITIALIZER(wmi_info_list);

 ACPI_SERIAL_DECL(acpi_wmi, ACPI-WMI Mapping);

@@ -146,13 +145,13 @@ static ACPI_STATUSacpi_wmi_ec_handler(UINT32 
function,
void *region_context);
 #endif
 /* helpers */
-static ACPI_STATUS acpi_wmi_read_wdg_blocks(ACPI_HANDLE h);
+static ACPI_STATUS acpi_wmi_read_wdg_blocks(struct acpi_wmi_softc *sc,
ACPI_HANDLE h);
 static ACPI_STATUS acpi_wmi_toggle_we_event_generation(device_t dev,
struct wmi_info *winfo,
enum event_generation_state state);
 static int acpi_wmi_guid_string_to_guid(const UINT8 *guid_string,
UINT8 *guid);
-static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string(
+static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string(struct
acpi_wmi_softc *sc,
const char *guid_string);

 static d_open_t acpi_wmi_wmistat_open;
@@ -240,7 +239,7 @@ acpi_wmi_attach(device_t dev)
ACPI_SERIAL_BEGIN(acpi_wmi);
sc-wmi_dev = dev;
sc-wmi_handle = acpi_get_handle(dev);
-   TAILQ_INIT(wmi_info_list);
+   TAILQ_INIT(sc-wmi_info_list);
 #if 0
/* XXX Only works with one EC, but nearly all systems only have one. */
if ((sc-ec_dev = devclass_get_device(devclass_find(acpi_ec), 0))
@@ -263,7 +262,7 @@ acpi_wmi_attach(device_t dev)
acpi_wmi_notify_handler);
}
 #endif
-   else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks(
+   else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks(sc,
sc-wmi_handle {
device_printf(sc-wmi_dev, couldn't parse _WDG - %s\n,
AcpiFormatException(status));
@@ -318,11 +317,11 @@ acpi_wmi_detach(device_t dev)
AcpiRemoveAddressSpaceHandler(sc-wmi_handle,
ACPI_ADR_SPACE_EC, acpi_wmi_ec_handler);
 #endif
-   TAILQ_FOREACH_SAFE(winfo, wmi_info_list, wmi_list, tmp) {
+   TAILQ_FOREACH_SAFE(winfo, sc-wmi_info_list, wmi_list, tmp) {
if (winfo-event_handler)
acpi_wmi_toggle_we_event_generation(dev,
winfo, EVENT_GENERATION_OFF);
-   TAILQ_REMOVE(wmi_info_list, winfo, wmi_list);
+   TAILQ_REMOVE(sc-wmi_info_list, winfo, wmi_list);
free(winfo, M_ACPIWMI);
}
if (sc-wmistat_bufptr != -1) {
@@ -347,12 +346,14 @@ acpi_wmi_detach(device_t dev)
 static int
 acpi_wmi_provides_guid_string_method(device_t dev, const char *guid_string)
 {
+   struct acpi_wmi_softc *sc;
struct wmi_info *winfo;
int ret;

+   sc = device_get_softc(dev);
ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__);
ACPI_SERIAL_BEGIN(acpi_wmi);
-   winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string);
+   winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string);
ret = (winfo == NULL)?0:winfo-ginfo.max_instance+1;
ACPI_SERIAL_END(acpi_wmi);

@@ -378,7 +379,7 @@ acpi_wmi_evaluate_call_method(device_t dev, const char
*guid_string,

sc = device_get_softc(dev);
ACPI_SERIAL_BEGIN(acpi_wmi);
-   if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string))
+   if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string))
== NULL)
status = AE_NOT_FOUND;
else if (!(winfo-ginfo.flags  ACPI_WMI_REGFLAG_METHOD))
@@ -420,6 +421,7 @@ static ACPI_STATUS
 acpi_wmi_install_event_handler_method(device_t dev, const char *guid_string,
 ACPI_NOTIFY_HANDLER event_handler, void *data)
 {
+   struct acpi_wmi_softc 

Re: notify userland about C-state changes

2012-10-03 Thread Andriy Gapon
on 03/10/2012 20:40 Ian Smith said the following:
 So are you talking about a devd notification to trigger activity like 
 the AC/battery script, or a sysctl that scripts could poll, or?

devd notification like for AC line status change.

-- 
Andriy Gapon
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org