Re: asmc(4) improvements

2015-12-22 Thread Mark Kettenis 
> Date: Tue, 22 Dec 2015 12:42:38 +0100
> From: Joerg Jung 
> 
> On Mon, Dec 21, 2015 at 10:38:24PM +0100, Mark Kettenis wrote:
> > There were two reasons for this slowness:
> > 
> > 1. The asmc_command() function does additional reads as a "sanity
> >flush".  We had to wait for these reads to time out, which took a
> >significant fraction of a second.  On my system, I neversaw any of
> >these flusing reads succeed.  So I removed that bit of code.
> 
> I added this sanity flush, because Apple seems to keep changing the
> returned number of bytes for some keys depending on the firmware
> revision.  An example for are the light sensors keys "ALVn": on newer
> Macbooks they return 10 bytes, while on older they return only 6 Bytes.
> The reason is that newer Macbooks provide the Lux value directly
> (instead of ADC raw data) in the added four bytes (see asmc_light).
> 
> So from my understanding: if the buffer is not emptied/flushed you might
> read the data from previous command with the next key? Maybe I got that
> wrong?

I actually suspect that the SMC will clear the OBF flag whenever you
send it a new command.  If that is indeed the case, flushing the read
buffer should not be necessary.

Re: asmc(4) improvements

2015-12-22 Thread Joerg Jung 
On Mon, Dec 21, 2015 at 10:38:24PM +0100, Mark Kettenis wrote:
> The asmc(4) driver is a bit slow.  On my MacBookPro12,1 it takes a
> couple of minutes to probe all the sensors.  And changing the keyboard
> backlight takes a couple of seconds.  This is especially annoying when
> you're writing a diff to bind that functionality to the keys reserved
> for this purpose on the keyboard.
> 
> Turns out the chip used for the Apple SMC is my old friend the H8S
> microcontroller (see lom(4) on sparc64).  With that knowledge in hand,
> it was fairly obvious what was going wrong.  The driver didn't check
> whether the chip input buffer was full before writing to it.  That
> caused commands to get lost.  With that fixed, comunication with the
> chip seems to be reliable, but still somewhat slow.  

Now, that really is an improvement. Thanks for looking into this and the
earlier bug fix x-mas present!

> There were two reasons for this slowness:
> 
> 1. The asmc_command() function does additional reads as a "sanity
>flush".  We had to wait for these reads to time out, which took a
>significant fraction of a second.  On my system, I neversaw any of
>these flusing reads succeed.  So I removed that bit of code.

I added this sanity flush, because Apple seems to keep changing the
returned number of bytes for some keys depending on the firmware
revision.  An example for are the light sensors keys "ALVn": on newer
Macbooks they return 10 bytes, while on older they return only 6 Bytes.
The reason is that newer Macbooks provide the Lux value directly
(instead of ADC raw data) in the added four bytes (see asmc_light).

So from my understanding: if the buffer is not emptied/flushed you might
read the data from previous command with the next key? Maybe I got that
wrong?

> 2. Failing commands were retried up to 10 times.  I assume this was
>necessary because writing to the chip was unreliable.  

Yes.

>I reduce it to 3 retries.

Makes sense with your buf fix.
 
> 3. The timouts for individual reads and writes were quite high.
>Especially because the code used tsleep(), which means a context
>switch could happen and we'd sleep longer than intended.

Yes.

> Since I also noticed that the command to set the keyboard backlight
> succeeded initially (when a simple delay was used) but failed later
> (when tsleep was used), I concluded that the SMC times out as well if
> we didn't send the complete command within a certain time.  

I think this conclusion is right.  That is what I have seen in my tests
as well.

> Such a minimum time is hard to guarantee if we use tsleep.  So this
> driverreally has to use an actual (spinning) delay, just like what I
> did in my lom(4) driver.
> 
> That sounds worse than it is.  Typically we spin only for a short time
> (500 us seems to be typical) for read and write operations that
> succeed.  So I clamped it at 5 ms.  With the diff below, the asmc
> taskq consumes about the same amount of CPU as the acpi thread.  I
> think that is perfectly acceptable.

Agreed, that totally makes sense. I just added the tsleep() delays to
make things working... now, with your input buffer fix they are not
really needed anymore.
 
> However, since Apple's SMC implementation almost certainly changed
> over the years, it would be good to test this diff on a wider range of
> Apple hardware.  Please check that all sensors are still present and
> are properly updated after applying this diff.

Works fine here.

ok jung@  (but we really should discuss the sanity flush removal)
 
> Thanks,
> 
> Mark
> 
> 
> Index: asmc.c
> ===
> RCS file: /cvs/src/sys/dev/isa/asmc.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 asmc.c
> --- asmc.c15 Dec 2015 20:58:22 -  1.21
> +++ asmc.c21 Dec 2015 21:35:05 -
> @@ -44,7 +44,11 @@
>  #define ASMC_WRITE   0x11/* SMC write command */
>  #define ASMC_INFO0x13/* SMC info/type command */
>  
> -#define ASMC_RETRY   10
> +#define ASMC_OBF 0x01/* Output buffer full */
> +#define ASMC_IBF 0x02/* Input buffer full */
> +#define ASMC_ACCEPT  0x04
> +
> +#define ASMC_RETRY   3
>  #define ASMC_MAXLEN  32  /* SMC maximum data size len */
>  #define ASMC_NOTFOUND0x84/* SMC status key not found */
>  
> @@ -385,11 +389,8 @@ asmc_kbdled(void *arg)
>   int r;
>  
>   if ((r = asmc_try(sc, ASMC_WRITE, "LKSB", buf, 2)))
> -#if 0 /* todo: write error, as no 0x04 wait status, but led is changed */
>   printf("%s: keyboard backlight failed (0x%x)\n",
>   sc->sc_dev.dv_xname, r);
> -#endif
> - ;
>  }
>  
>  int
> @@ -436,44 +437,57 @@ asmc_status(struct asmc_softc *sc)
>  }
>  
>  static int
> -asmc_wait(struct asmc_softc *sc, uint8_t m)
> +asmc_write(struct asmc_softc *sc, uint8_t off, uint8_t val)
>  {
> - int us;
> + uint8_t str;
> + int i;
>  
> - for (us = (2 << 4); us < (2 << 16); us *=

Re: asmc(4) improvements

2015-12-21 Thread Bryan Vyhmeister 
On Mon, Dec 21, 2015 at 10:38:24PM +0100, Mark Kettenis wrote:
> However, since Apple's SMC implementation almost certainly changed
> over the years, it would be good to test this diff on a wider range of
> Apple hardware.  Please check that all sensors are still present and
> are properly updated after applying this diff.

Applied patch and here is my dmesg from before (Dec 19 snapshot) and
after (today's tree from an hour ago or so) on the MacBookAir7,2 as well
as the output of sysctl hw.sensors.asmc0. I didn't have trouble with a
long wait for asmc(4) initialization or anything before however. I can
also test on a MacBookAir6,1 shortly and probably also a MacBookPro10,2.

Bryan


OpenBSD 5.8-current (GENERIC.MP) #1757: Sat Dec 19 08:17:18 MST 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
RTC BIOS diagnostic error 
ff
real mem = 8469352448 (8077MB)
avail mem = 8208539648 (7828MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x8afad000 (32 entries)
bios0: vendor Apple Inc. version "MBA71.88Z.0166.B06.1506051511" date 06/05/2015
bios0: Apple Inc. MacBookAir7,2
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT 
SSDT MCFG DMAR
acpi0: wakeup devices PEG0(S3) EC__(S3) HDEF(S3) RP01(S3) RP02(S3) RP03(S4) 
ARPT(S4) RP05(S3) RP06(S3) SPIT(S3) XHC1(S3) ADP1(S3) LID0(S3)
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) i7-5650U CPU @ 2.20GHz, 2100.35 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
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 100MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-5650U CPU @ 2.20GHz, 2100.00 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,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpiec0 at acpi0
acpimcfg0 at acpi0 addr 0xe000, bus 0-155
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus 2 (RP02)
acpiprt4 at acpi0: bus 3 (RP03)
acpiprt5 at acpi0: bus 5 (RP05)
acpiprt6 at acpi0: bus 4 (RP06)
acpicpu0 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@276 mwait.1@0x60), C2(200@148 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpibat0 at acpi0: BAT0 model "3545797981023400290" type 3545797981528607052 
oem "3545797981528608836"
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0

asmc(4) improvements

2015-12-21 Thread Mark Kettenis 
The asmc(4) driver is a bit slow.  On my MacBookPro12,1 it takes a
couple of minutes to probe all the sensors.  And changing the keyboard
backlight takes a couple of seconds.  This is especially annoying when
you're writing a diff to bind that functionality to the keys reserved
for this purpose on the keyboard.

Turns out the chip used for the Apple SMC is my old friend the H8S
microcontroller (see lom(4) on sparc64).  With that knowledge in hand,
it was fairly obvious what was going wrong.  The driver didn't check
whether the chip input buffer was full before writing to it.  That
caused commands to get lost.  With that fixed, comunication with the
chip seems to be reliable, but still somewhat slow.  There were two
reasons for this slowness:

1. The asmc_command() function does additional reads as a "sanity
   flush".  We had to wait for these reads to time out, which took a
   significant fraction of a second.  On my system, I neversaw any of
   these flusing reads succeed.  So I removed that bit of code.

2. Failing commands were retried up to 10 times.  I assume this was
   necessary because writing to the chip was unreliable.  I reduce it
   to 3 retries.

3. The timouts for individual reads and writes were quite high.
   Especially because the code used tsleep(), which means a context
   switch could happen and we'd sleep longer than intended.

Since I also noticed that the command to set the keyboard backlight
succeeded initially (when a simple delay was used) but failed later
(when tsleep was used), I concluded that the SMC times out as well if
we didn't send the complete command within a certain time.  Such a
minimum time is hard to guarantee if we use tsleep.  So this
driverreally has to use an actual (spinning) delay, just like what I
did in my lom(4) driver.

That sounds worse than it is.  Typically we spin only for a short time
(500 us seems to be typical) for read and write operations that
succeed.  So I clamped it at 5 ms.  With the diff below, the asmc
taskq consumes about the same amount of CPU as the acpi thread.  I
think that is perfectly acceptable.

However, since Apple's SMC implementation almost certainly changed
over the years, it would be good to test this diff on a wider range of
Apple hardware.  Please check that all sensors are still present and
are properly updated after applying this diff.

Thanks,

Mark


Index: asmc.c
===
RCS file: /cvs/src/sys/dev/isa/asmc.c,v
retrieving revision 1.21
diff -u -p -r1.21 asmc.c
--- asmc.c  15 Dec 2015 20:58:22 -  1.21
+++ asmc.c  21 Dec 2015 21:35:05 -
@@ -44,7 +44,11 @@
 #define ASMC_WRITE 0x11/* SMC write command */
 #define ASMC_INFO  0x13/* SMC info/type command */
 
-#define ASMC_RETRY 10
+#define ASMC_OBF   0x01/* Output buffer full */
+#define ASMC_IBF   0x02/* Input buffer full */
+#define ASMC_ACCEPT0x04
+
+#define ASMC_RETRY 3
 #define ASMC_MAXLEN32  /* SMC maximum data size len */
 #define ASMC_NOTFOUND  0x84/* SMC status key not found */
 
@@ -385,11 +389,8 @@ asmc_kbdled(void *arg)
int r;
 
if ((r = asmc_try(sc, ASMC_WRITE, "LKSB", buf, 2)))
-#if 0 /* todo: write error, as no 0x04 wait status, but led is changed */
printf("%s: keyboard backlight failed (0x%x)\n",
sc->sc_dev.dv_xname, r);
-#endif
-   ;
 }
 
 int
@@ -436,44 +437,57 @@ asmc_status(struct asmc_softc *sc)
 }
 
 static int
-asmc_wait(struct asmc_softc *sc, uint8_t m)
+asmc_write(struct asmc_softc *sc, uint8_t off, uint8_t val)
 {
-   int us;
+   uint8_t str;
+   int i;
 
-   for (us = (2 << 4); us < (2 << 16); us *= 2) { /* wait up to 128 ms */
-   (!sc->sc_sensor_task) ? delay(us) :
-   tsleep(>sc_taskq, 0, "asmc",
-   (us * hz + 99) / 100 + 1);
-   if (bus_space_read_1(sc->sc_iot, sc->sc_ioh, ASMC_COMMAND) & m)
-   return 1;
+   for (i = 500; i > 0; i--) {
+   str = bus_space_read_1(sc->sc_iot, sc->sc_ioh, ASMC_COMMAND);
+   if ((str & ASMC_IBF) == 0)
+   break;
+   delay(10);
}
-   return 0;
-}
+   if (i == 0)
+   return ETIMEDOUT;
 
-static int
-asmc_write(struct asmc_softc *sc, uint8_t off, uint8_t val)
-{
bus_space_write_1(sc->sc_iot, sc->sc_ioh, off, val);
-   if (asmc_wait(sc, 0x04)) /* write accepted? */
-   return 0;
-   return 1;
+
+   for (i = 500; i > 0; i--) {
+   str = bus_space_read_1(sc->sc_iot, sc->sc_ioh, ASMC_COMMAND);
+   if (str & ASMC_ACCEPT)
+   break;
+   delay(10);
+   }
+   if (i == 0)
+   return ETIMEDOUT;
+
+   return 0;
 }
 
 static int
 asmc_read(struct asmc_softc *sc, uint8_t off, uint8_t *buf)
 {
-   if (asmc_wait(sc, 0x01)) { /*

Re: asmc(4) improvements

2015-12-21 Thread Theo Buehler 
> However, since Apple's SMC implementation almost certainly changed
> over the years, it would be good to test this diff on a wider range of
> Apple hardware.  Please check that all sensors are still present and
> are properly updated after applying this diff.

Seems to be a significant improvement on this MacBookPro 4,1:

All sensors show up in sysctl immediately after boot.  Before the patch,
the fans were detected only after about five minutes uptime.

The exact same sensors are detected.

All sensors seem to have about the same values as before the patch both
when the machine is idle and when it is under load.

Responsiveness of keyboard.backlight adjustment is now immediate rather
than delayed by about one second.

OpenBSD 5.9-beta (GENERIC.MP) #188: Tue Dec 22 07:03:10 CET 2015
t...@idefix.ethz.ch:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2110599168 (2012MB)
avail mem = 2042535936 (1947MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe (45 entries)
bios0: vendor Apple Inc. version "MBP41.88Z.00C1.B03.0802271651" date 02/27/08
bios0: Apple Inc. MacBookPro4,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP HPET APIC MCFG ASF! SBST ECDT SSDT SSDT SSDT SSDT SSDT
acpi0: wakeup devices ADP1(S3) LID0(S3) ARPT(S3) GIGE(S3) UHC1(S3) UHC2(S3) 
UHC3(S3) UHC4(S3) UHC5(S3) EHC1(S3) EHC2(S3) EC__(S3)
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)2 Duo CPU T8300 @ 2.40GHz, 2394.46 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu0: 3MB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 199MHz
cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2.1.3, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz, 2394.00 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,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,NXE,LONG,LAHF,PERF,SENSOR
cpu1: 3MB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 1
acpimcfg0 at acpi0 addr 0xf000, bus 0-255
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEGP)
acpiprt2 at acpi0: bus 3 (RP03)
acpiprt3 at acpi0: bus 11 (RP05)
acpiprt4 at acpi0: bus 12 (RP06)
acpiprt5 at acpi0: bus 13 (PCIB)
acpicpu0 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
mwait), PSS
acpicpu1 at acpi0: !C3(100@57 mwait.3@0x31), !C2(500@1 mwait@0x10), C1(1000@1 
mwait), PSS
acpiac0 at acpi0: AC unit online
acpibtn0 at acpi0: LID0
acpibtn1 at acpi0: PWRB
acpibtn2 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "14127832176087873" type 14127832377542988 oem 
"14127833101004627"
acpivideo0 at acpi0: GFX0
cpu0: Enhanced SpeedStep 2394 MHz: speeds: 2400, 2200, 2000, 1800, 1600, 1400, 
1200, 800 MHz
memory map conflict 0xf00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict 0xfffa/0x3
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel GM965 Host" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel GM965 PCIE" rev 0x03: msi
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "NVIDIA GeForce 8600M GT" rev 0xa1
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
uhci0 at pci0 dev 26 function 0 "Intel 82801H USB" rev 0x04: apic 1 int 20
uhci1 at pci0 dev 26 function 1 "Intel 82801H USB" rev 0x04: apic 1 int 16
ehci0 at pci0 dev 26 function 7 "Intel 82801H USB" rev 0x04: apic 1 int 21
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
azalia0 at pci0 dev 27 function 0 "Intel 82801H HD Audio" rev 0x04: msi
azalia0: codecs: Realtek ALC885
audio0 at azalia0
ppb1 at pci0 dev 28 function 0 "Intel 82801H PCIE" rev 0x04: msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 28 function 2 "Intel 82801H PCIE" rev 0x04: msi
pci3 at ppb2 bus 3
ppb3 at pci0 dev 28 function 4 "Intel 82801H PCIE" rev 0x04: msi
pci4 at ppb3 bus 11
"Broadcom BCM4321" rev 0x05 at pci4 dev 0 function 0 not configured
ppb4 at pci0 dev 28 function 5 "Intel 82801H PCIE" rev 0x04: msi
pci5 at ppb4 bus 12
mskc0 at pci5 dev 0 function 0 "Marvell Yukon 88E8058" rev 0x13, Yukon-2 EC 
Ultra rev. B0 (0x3): apic 1 int 17
msk0 at mskc0 port A: address 00:22:41:32:fe:f1
eephy0 at msk0 phy 0: 88E1149 Gigabit PHY, rev. 1
uhci2 at pci0 dev 29 function 0 "Intel 82801H USB" rev 0x04: apic 1 int 16
uhci3 at pci0 dev 29 function 1 "Intel 82801H USB" rev

Re: asmc(4) improvements

2015-12-21 Thread Bryan Vyhmeister 
On Tue, Dec 22, 2015 at 08:30:15AM +0100, Theo Buehler wrote:
> Responsiveness of keyboard.backlight adjustment is now immediate
> rather than delayed by about one second.

I didn't test keyboard.backlight adjustment responsiveness initially on
the MacBookAir7,2 but, as you said as well, it is instant where before
it did not work every time and there was a significant delay with any
change.

Bryan