[CFT] Sparse Cstate Support -- Its possible, that I don't know what I'm doing.

[Andriy Gapon]

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