Date: Wed, 27 Feb 2008 09:54:38 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info Message-ID: <47C5173E.40207@icyb.net.ua> In-Reply-To: <47C32D3C.2020205@icyb.net.ua> References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> <47C30201.3060501@root.org> <47C32D3C.2020205@icyb.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 25/02/2008 23:03 Andriy Gapon said the following:
> Nate,
> these are very good points. It seems that I wrote something very
> specific to my case and didn't consider other scenarios. I completely
> forgot about SMP case.
> I need to think more about this.
> A possible blanket solution would be to probe/attach all and any cpu
> child devices after pci bus is attached. But I don't know if this is a
> viable solution in general and if it's possible to implement at all.
I looked through some code while pursuing the above idea. Of course,
things are more complicated if one has to consider legacy scenarios (no
ACPI) too, but for the scope of this issue I sticked to the case when
ACPI is available.
It seems that children of acpi are added in acpi_probe_children
function. First we walk over all devices declared in DSDT and create
child devices for those that are interesting to us. AcpiWalkNamespace
with acpi_probe_child is used for that. When we call BUS_ADD_CHILD for a
device we typically specify an order value based on a device's
level/depth. For some special devices we set specific (early) order
value in acpi_probe_order (based on HID).
Then we add devices that are not auto-detected but rather add themselves
via device_identify method. Then we perform probe and attach for all
added devices via bus_generic_attach, and the devices are probed and
attached according to their 'order' attribute.
>From this, my conclusion is that relative order of cpu and pci bridge is
generally undetermined in this case. This is because neither of them has
a specific order assigned. So their order depends on their level and,
well, order in DSDT.
Typically, processor would have a smaller or equal level compared to
host-pci bridge. In my particular case I believe that the levels are the
same:
\_PR_.CPU0
\_SB_.PCI0
And processor appears earlier in DSDT, so they both have the same order
value but processor is added earlier.
Another thing is that acpi_cpu and acpi_pcib_acpi (using their "full
names") are the buses themselves, so they identify/probe/attach their
children in their attach methods. Thus, whichever has earlier order will
also probe and attach (all of) its children earlier.
So what I am getting at - it is certainly not hard to make
acpi_pcib_acpi (and consecutively pci) be attached earlier than
acpi_cpu. All is needed is to add another special case in
acpi_probe_order after the existing ones, I actually did it as an
experiment:
else if (acpi_MatchHid(handle, "PNP0A03"))
*order = 4;
This worked for me as expected and without any side effects.
But I have a big concern about whether we have any devices/drivers that
rely on a current typical order. That is, drivers that expect cpu
device/bus to be already probed and attached at the time when
probe/attach is called for something on pci bus.
I guess one example here is famous ichss that adds a child to cpu bus in
its pci probe routine, and calls device_probe_and_attach for it in the
same place too. I guess that while BUS_ADD_CHILD should work at that
place, device_probe_and_attach may not because cpu itself is not probed
and attached yet.
On the other hand, as I said in the beginning, I think that even now
there are no strict guarantees about the order, it just happens to work.
Anyway, I am not sure if the discussed change in ordering has any merit.
It seems that whatever the order it would be convenient in some places
and inconvenient in others, so some jumping through the hoops is inevitable.
I wonder if it would be possible to create some mechanism for attaching
"important" devices first and then the rest later. E.g. cpu and pcib+pci
are attached first (in whatever order), then their children are attached
later (in whatever order). What is important is that all those "late"
children can expect both cpu and pci to be fully available.
P.S. sorry for high-jacking a topic, an unrelated question: shouldn't
ISA PnP devices get configured (assigned resources) before any PCI devices ?
http://docs.FreeBSD.org/cgi/mid.cgi?47C338D5.2080906
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C5173E.40207>