Re: acpiec(4): clear events based on vendor
On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? I'm confused :-) While at it I tried some recent snapshot kernels: - bsd.mp from May 23: shutdown because of wront acpitz temperatur - bsd.mp from June 6: hw.sensors.acpibat0.* recognized no reaction when I connect/reconnect the power supply - bsd.mp from June 10: same as June 6 # dmesg OpenBSD 5.5-current (GENERIC.MP) #172: Fri Jun 6 11:11:50 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769638912 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03,
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) While at it I tried some recent snapshot kernels: - bsd.mp from May 23: shutdown because of wront acpitz temperatur - bsd.mp from June 6: hw.sensors.acpibat0.* recognized no reaction when I connect/reconnect the power supply - bsd.mp from June 10: same as June 6 # dmesg OpenBSD 5.5-current (GENERIC.MP) #172: Fri Jun 6 11:11:50 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769638912 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1
Re: acpiec(4): clear events based on vendor
Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware.
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines.
Re: acpiec(4): clear events based on vendor
On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines. /me ducks :)
Re: acpiec(4): clear events based on vendor
On Wed, Jun 11, 2014 at 02:49:41PM -0700, Mike Larkin wrote: On Thu, Jun 12, 2014 at 12:45:23AM +0300, Paul Irofti wrote: On Wed, Jun 11, 2014 at 09:42:56PM +0200, Mark Kettenis wrote: Date: Wed, 11 Jun 2014 08:40:51 +0200 From: Remi Locherer remi.loche...@relo.ch On Wed, Jun 11, 2014 at 09:11:54AM +0300, Paul Irofti wrote: On Tue, Jun 10, 2014 at 11:50:02PM +0200, Remi Locherer wrote: On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. So this time it works... Did you apply the diff on top of a current sys? I did a cvs up on June 10 and applied this diff on top of that. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. And this time it does not? With this diff hw.sensors.acpiac0.indicator0 works correctly but hw.sensors.acpibat0.amphourX does not. With snapshot kernels from June 6 and June 10 it's the other way round. I'm confused :-) I can imagin - the complexity of acpi combined with Samsung's implementation and my imprecise description ... ;-) Our acpi code does something wrong. This seems to be the root cause of the acpitz(4) problems that we're seeing on a wider variety of hardware. I really think we should try to fix that broader issue before trying to fix this more specific suspend/resume issue on Samsung hardware. Sure. This is not at all urgent. It can wait for someone to fix acpitz(4) on those machines. /me ducks :) I don't think there's any need for ducking, last I remember you don't own a Samsung machine.
acpiec(4): clear events based on vendor
Hi,
This is adding vendor-based support to my initial acpiec(4) clear events
work[1].
It seems some machines need this only during resume, while other need it
at attach (boot) as well. And then there's the group of machines that
completely rely on having events in the queue on both boot and resume.
And so, with this diff, we'll be able to pick where to enable event clearing.
I added a first example based on the feedback I got during the first version
of this diff.
Any comments? Okay?
[1] - http://marc.info/?l=openbsd-techm=139586828926337w=2
Index: acpidev.h
===
RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
retrieving revision 1.34
diff -u -p -r1.34 acpidev.h
--- acpidev.h 23 May 2014 19:17:39 - 1.34
+++ acpidev.h 10 Jun 2014 12:42:00 -
@@ -333,6 +333,10 @@ struct acpiec_softc {
struct acpiec_event sc_events[ACPIEC_MAX_EVENTS];
int sc_gotsci;
int sc_glk;
+
+ /* Quirks: clear events on attatch/resume */
+ charsc_clear_attatch;
+ charsc_clear_resume;
};
void acpibtn_disable_psw(void);
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.49
diff -u -p -r1.49 acpiec.c
--- acpiec.c21 May 2014 02:14:07 - 1.49
+++ acpiec.c10 Jun 2014 12:42:00 -
@@ -34,6 +34,7 @@
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+intacpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *);
@@ -82,7 +84,8 @@ void acpiec_unlock(struct acpiec_softc
intacpiec_reg(struct acpiec_softc *);
struct cfattach acpiec_ca = {
- sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
+ sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
+ NULL, acpiec_activate
};
struct cfdriver acpiec_cd = {
@@ -91,6 +94,32 @@ struct cfdriver acpiec_cd = {
const char *acpiec_hids[] = { ACPI_DEV_ECD, 0 };
+/* needed by acpiec_clear_events */
+extern char *hw_vendor, *hw_prod;
+
+struct ec_quirks_description {
+ char *vendor;
+ char *prod;
+ char attatch;
+ char resume;
+};
+
+static const struct ec_quirks_description ec_quirks[] = {
+ /*
+* Header description:
+*
+* The first two entries define the machine model based on information
+* from BIOS in the following order: VENDOR, PRODUCT
+*
+* The last two values state if and when clearing events should be done:
+* during attatch and/or during resume.
+*/
+
+ /* ThinkPad x120e */
+ { LENOVO, 05962PU, 1, 1, },
+};
+
+
void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
@@ -274,6 +303,8 @@ acpiec_attach(struct device *parent, str
struct acpi_attach_args *aa = aux;
struct aml_value res;
+ int i;
+
sc-sc_acpi = (struct acpi_softc *)parent;
sc-sc_devnode = aa-aaa_node;
@@ -297,6 +328,17 @@ acpiec_attach(struct device *parent, str
acpi_set_gpehandler(sc-sc_acpi, sc-sc_gpe, acpiec_gpehandler,
sc, 1);
#endif
+
+ for (i = 0; i nitems(ec_quirks); i++)
+ if ((!strcmp(hw_vendor, ec_quirks[i].vendor))
+ (!strcmp(hw_prod, ec_quirks[i].prod))) {
+ sc-sc_clear_attatch = ec_quirks[i].attatch;
+ sc-sc_clear_resume = ec_quirks[i].resume;
+ break;
+ }
+
+ if (sc-sc_clear_attatch)
+ acpiec_clear_events(sc);
if (aml_evalname(sc-sc_acpi, sc-sc_devnode, _GLK, 0, NULL, res))
sc-sc_glk = 0;
@@ -308,6 +350,21 @@ acpiec_attach(struct device *parent, str
printf(\n);
}
+int
+acpiec_activate(struct device *self, int act)
+{
+ struct acpiec_softc *sc = (struct acpiec_softc *)self;
+
+
+ switch (act) {
+ case DVACT_RESUME:
+ if (sc-sc_clear_resume)
+ acpiec_clear_events(sc);
+ break;
+ }
+ return (0);
+}
+
void
acpiec_get_events(struct acpiec_softc *sc)
{
@@ -553,4 +610,17 @@ acpiec_unlock(struct acpiec_softc *sc)
}
sc-sc_ecbusy = 0;
+}
+
+void
+acpiec_clear_events(struct acpiec_softc *sc)
+{
+ int i;
+
+ for (i = 0; i 100; i++) {
+ acpiec_write_cmd(sc,
Re: acpiec(4): clear events based on vendor
After discussions with Theo we decided to walk the table where needed
instead of using the soft state variables.
Also adding all the Samsung models to the quirks table (as per the
Linux EC quirks table).
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.49
diff -u -p -r1.49 acpiec.c
--- acpiec.c21 May 2014 02:14:07 - 1.49
+++ acpiec.c10 Jun 2014 15:18:59 -
@@ -34,6 +34,7 @@
intacpiec_match(struct device *, void *, void *);
void acpiec_attach(struct device *, struct device *, void *);
+intacpiec_activate(struct device *, int);
u_int8_t acpiec_status(struct acpiec_softc *);
u_int8_t acpiec_read_data(struct acpiec_softc *);
@@ -54,6 +55,7 @@ int acpiec_getregister(const u_int8_t *
void acpiec_wait(struct acpiec_softc *, u_int8_t, u_int8_t);
void acpiec_sci_event(struct acpiec_softc *);
+void acpiec_clear_events(struct acpiec_softc *);
void acpiec_get_events(struct acpiec_softc *);
@@ -82,7 +84,8 @@ void acpiec_unlock(struct acpiec_softc
intacpiec_reg(struct acpiec_softc *);
struct cfattach acpiec_ca = {
- sizeof(struct acpiec_softc), acpiec_match, acpiec_attach
+ sizeof(struct acpiec_softc), acpiec_match, acpiec_attach,
+ NULL, acpiec_activate
};
struct cfdriver acpiec_cd = {
@@ -91,6 +94,34 @@ struct cfdriver acpiec_cd = {
const char *acpiec_hids[] = { ACPI_DEV_ECD, 0 };
+/* needed by acpiec_clear_events */
+extern char *hw_vendor, *hw_prod;
+
+struct ec_quirks_description {
+ char *vendor;
+ char *prod;
+};
+
+static const struct ec_quirks_description ec_quirks[] = {
+ /*
+* Header description:
+*
+* The entries define the machine model based on information
+* from BIOS in the following order: VENDOR, PRODUCT
+*
+*/
+
+ /* ThinkPad x120e */
+ { LENOVO, 05962PU },
+
+ /*
+* All Samsung models require this according to Linux
+* https://bugzilla.kernel.org/show_bug.cgi?id=44161
+*/
+ { SAMSUNG ELECTRONICS CO., LTD., NULL }
+};
+
+
void
acpiec_wait(struct acpiec_softc *sc, u_int8_t mask, u_int8_t val)
{
@@ -274,6 +305,8 @@ acpiec_attach(struct device *parent, str
struct acpi_attach_args *aa = aux;
struct aml_value res;
+ int i;
+
sc-sc_acpi = (struct acpi_softc *)parent;
sc-sc_devnode = aa-aaa_node;
@@ -297,7 +330,16 @@ acpiec_attach(struct device *parent, str
acpi_set_gpehandler(sc-sc_acpi, sc-sc_gpe, acpiec_gpehandler,
sc, 1);
#endif
-
+
+ for (i = 0; i nitems(ec_quirks); i++)
+ if ((!strcmp(hw_vendor, ec_quirks[i].vendor))
+ (ec_quirks[i].prod == NULL ||
+ (!strcmp(hw_prod, ec_quirks[i].prod {
+ acpiec_clear_events(sc);
+ break;
+ }
+
+
if (aml_evalname(sc-sc_acpi, sc-sc_devnode, _GLK, 0, NULL, res))
sc-sc_glk = 0;
else if (res.type != AML_OBJTYPE_INTEGER)
@@ -308,6 +350,26 @@ acpiec_attach(struct device *parent, str
printf(\n);
}
+int
+acpiec_activate(struct device *self, int act)
+{
+ struct acpiec_softc *sc = (struct acpiec_softc *)self;
+ int i;
+
+ switch (act) {
+ case DVACT_RESUME:
+ for (i = 0; i nitems(ec_quirks); i++)
+ if ((!strcmp(hw_vendor, ec_quirks[i].vendor))
+ (ec_quirks[i].prod == NULL ||
+ (!strcmp(hw_prod, ec_quirks[i].prod {
+ acpiec_clear_events(sc);
+ break;
+ }
+ break;
+ }
+ return (0);
+}
+
void
acpiec_get_events(struct acpiec_softc *sc)
{
@@ -553,4 +615,17 @@ acpiec_unlock(struct acpiec_softc *sc)
}
sc-sc_ecbusy = 0;
+}
+
+void
+acpiec_clear_events(struct acpiec_softc *sc)
+{
+ int i;
+
+ for (i = 0; i 100; i++) {
+ acpiec_write_cmd(sc, EC_CMD_QR);
+ sc-sc_gotsci = 0;
+ if ((acpiec_status(sc) EC_STAT_SCI_EVT) != EC_STAT_SCI_EVT)
+ break;
+ }
}
Re: acpiec(4): clear events based on vendor
Date: Tue, 10 Jun 2014 18:25:33 +0300 From: Paul Irofti p...@irofti.net After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). This diff breaks my Samsung NC10. It provokes acpitz: critical temperature exceeded 144C, shutting down messages during boot. Below the dmesg from a standard -current kernel. OpenBSD 5.5-current (GENERIC.MP) #0: Tue Jun 10 22:25:11 CEST 2014 kette...@albeniz.sibelius.xs4all.nl:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF real mem = 1063612416 (1014MB) avail mem = 1033764864 (985MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 11/25/08, BIOS32 rev. 0 @ 0xfd5f0, SMBIOS rev. 2.5 @ 0xdf010 (36 entries) bios0: vendor Phoenix Technologies Ltd. version 03CA.MP00.20081125.KTW date 11/25/2008 bios0: SAMSUNG ELECTRONICS CO., LTD. NC10 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG TCPA TMOR APIC BOOT SLIC SSDT SSDT SSDT acpi0: wakeup devices HDEF(S4) PXS1(S4) PXS2(S4) PXS3(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB7(S3) SLT0(S4) SLT1(S4) SLT2(S4) SLT3(S4) SLT6(S4) LANC(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.2.0.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (GenuineIntel 686-class) 1.60 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE,LAHF,PERF ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 4 (PCIB) acpiec0 at acpi0 acpicpu0 at acpi0: C1, PSS acpicpu1 at acpi0: C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpitz0 at acpi0: critical temperature is 98 degC acpibat0 at acpi0: BAT1 type LION oem SAMSUNG Electronics acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: PWRB acpibtn2 at acpi0: SLPB acpivideo0 at acpi0: GFX0 bios0: ROM list: 0xc/0xec00! 0xdf000/0x1000! 0xe/0x1800! cpu0: Enhanced SpeedStep 1596 MHz: speeds: 1600, 1333, 1067, 800 MHz pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82945GME Host rev 0x03 vga1 at pci0 dev 2 function 0 Intel 82945GME Video rev 0x03 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x600 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82945GM Video rev 0x03 at pci0 dev 2 function 1 not configured azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Realtek ALC272 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: apic 1 int 17 pci1 at ppb0 bus 2 ath0 at pci1 dev 0 function 0 Atheros AR5424 rev 0x01: apic 1 int 16 ath0: AR5424 14.2 phy 7.0 rf 0.0, EU1W, address 00:24:2b:1d:6b:25 ppb1 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: apic 1 int 18 pci2 at ppb1 bus 3 mskc0 at pci2 dev 0 function 0 Marvell Yukon 88E8040 rev 0x13, Yukon-2 FE+ rev. A0 (0x0): apic 1 int 18 msk0 at mskc0 port A: address 00:13:77:b3:54:f0 eephy0 at msk0 phy 0: 88E3016 10/100 PHY, rev. 0 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 23 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 19 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 16 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb2 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci3 at ppb2 bus 4 ichpcib0 at pci0 dev 31 function 0 Intel 82801GBM LPC rev 0x02: PM disabled pciide0 at pci0 dev 31 function 2 Intel 82801GBM SATA rev 0x02: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility wd0 at pciide0 channel 0 drive 0: FUJITSU MHZ2160BH G2 wd0: 16-sector PIO, LBA48, 152627MB, 312581808 sectors wd0(pciide0:0:0):
Re: acpiec(4): clear events based on vendor
On Tue, Jun 10, 2014 at 06:25:33PM +0300, Paul Irofti wrote: After discussions with Theo we decided to walk the table where needed instead of using the soft state variables. Also adding all the Samsung models to the quirks table (as per the Linux EC quirks table). I tried this diff with my Samsung notebook. With sysctl hw.sensors or apm the state of the power supply is displayed correctly. If I change the status (disconnect or connect again) this is then also showed correctly. But a current kernel (checkout from June 10) with this patch applied does not show the acpibat0 sensor values correctly. While at it I tried some recent snapshot kernels: - bsd.mp from May 23: shutdown because of wront acpitz temperatur - bsd.mp from June 6: hw.sensors.acpibat0.* recognized no reaction when I connect/reconnect the power supply - bsd.mp from June 10: same as June 6 # dmesg OpenBSD 5.5-current (GENERIC.MP) #172: Fri Jun 6 11:11:50 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3881746432 (3701MB) avail mem = 3769638912 (3595MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe0970 (63 entries) bios0: vendor Phoenix Technologies Ltd. version P00ACX date 04/26/2013 bios0: SAMSUNG ELECTRONICS CO., LTD. 900X3F acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT ASF! HPET APIC MCFG FPDT SSDT SSDT UEFI MSDM UEFI UEFI acpi0: wakeup devices P0P1(S4) GLAN(S4) XHC_(S4) HDEF(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.42 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz, 1696.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (P0P1) acpiprt2 at acpi0: bus 1 (RP01) acpiprt3 at acpi0: bus -1 (RP02) acpiprt4 at acpi0: bus -1 (RP03) acpiprt5 at acpi0: bus 2 (RP04) acpiprt6 at acpi0: bus 3 (RP05) acpiprt7 at acpi0: bus -1 (RP06) acpiprt8 at acpi0: bus -1 (RP07) acpiprt9 at acpi0: bus -1 (RP08) acpiprt10 at acpi0: bus -1 (PEG0) acpiprt11 at acpi0: bus -1 (PEG1) acpiprt12 at acpi0: bus -1 (PEG2) acpiprt13 at acpi0: bus -1 (PEG3) acpiec0 at acpi0 acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpicpu2 at acpi0: C3, C2, C1, PSS acpicpu3 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: FN00, resource for FAN0 acpipwrres1 at acpi0: FN01, resource for FAN1 acpipwrres2 at acpi0: FN02, resource for FAN2 acpipwrres3 at acpi0: FN03, resource for FAN3 acpipwrres4 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 106 degC acpitz1 at acpi0: critical temperature is 106 degC acpibat0 at acpi0: BAT1 type LION oem SAMSUNG Electronics acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0
