on 20/06/2012 19:44 Sean Bruno said the following: > On Tue, 2012-06-19 at 09:02 -0700, Sean Bruno wrote: >> http://people.freebsd.org/~sbruno/acpi_cpu_cstate_sparse.txt > > also, I wanted to point out that I'm returning BUS_PROBE_GENERIC here. > > I want to emulate the Intel acpi_idle code that exists in linux-land and > I *thought* that I could setup an acpi_cpu_idle module that would come > in at a higher priority on Intel cpus, however there's some SYSINIT() > hackery going on that I don't know how to handle gracefully. I'm not > sure how to proceed with a different idle module here. thoughts? > > e.g. > > static void > acpi_cpu_postattach(void *unused __unused) > { > device_t *devices; > int err; > int i, n; > > err = devclass_get_devices(acpi_cpu_devclass, &devices, &n); > if (err != 0) { > printf("devclass_get_devices(acpi_cpu_devclass) failed\n"); > return; > } > for (i = 0; i < n; i++) > bus_generic_probe(devices[i]); > for (i = 0; i < n; i++) > bus_generic_attach(devices[i]); > free(devices, M_TEMP); > } > > SYSINIT(acpi_cpu, SI_SUB_CONFIGURE, SI_ORDER_MIDDLE, > acpi_cpu_postattach, NULL); > >
Just a little bit of explanation for the code. acpi_cpu driver is attached very early because it does some ACPI configuration in its attach method (_OSC/_PDC calls) and correct behavior of other ACPI drivers may depend on this. On the other hand, acpi_cpu acts as a bus and has child devices. Some of those children can not attach that early because they need more of the system to be initialized (e.g. PCI bus). Hence the SYSINIT hack to attach them later. -- Andriy Gapon _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "[email protected]"
