Re: newbus questions
In message [EMAIL PROTECTED], Nate Lawson wrote:
I'm working on ECDT support for ACPI and ran into a couple newbus-related
questions.
1. I'm using the identify entry as a way to get called early on in the
boot process. However, this does not happen before $PIR evaluation. How
should I hook in a routine for pre-$PIR execution?
It may be called in
if (ACPI_FAILURE(status = AcpiInstallAddressSpaceHandler(ACPI_ROOT_OBJECT,
ACPI_ADR_SPACE_PCI_CONFIG,
ACPI_DEFAULT_HANDLER,
NULL, NULL))) {
device_printf(dev, could not initialise PciConfig handler: %s\n, AcpiF
ormatException(status));
goto out;
at acpi_attach().
2. I need to call bus_alloc_resource() to get access to some io ports.
However, calling BUS_READ_IVAR in the identify routine gets a bad pointer
deref. So how do I get a handle to use for allocating the IO ports
(first arg of bus_alloc_resource)?
If you want to use IDENTIFY method, you have to imprement
'bus_driver_added' method on parent driver to initialize ivars in
device object.
3. It appears bus_alloc_resource() takes a range of values. If I know the
exact value to use, I request it via value, value instead of 0, ~0.
Is this correct?
It is correct in that context. When parent driver enumlate device and
set the resorce for device, That is used for allocate 'default' resource.
The framework for this code is in ec_identify() and ec_attach() in
sys/dev/acpica/acpi_ec.c.
You may want to set up ACPI EC register space before ACPI name space is
probed. So I think it is possible to call the initialization routine
in acpi_attach() explicitly for the time being.
The generalized way is that we have to imprement simple ACPI table
parser other than DSDT that is used before ACPI-CA initialization.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : I'm working on ECDT support for ACPI and ran into a couple newbus-related : questions. : : 1. I'm using the identify entry as a way to get called early on in the : boot process. However, this does not happen before $PIR evaluation. How : should I hook in a routine for pre-$PIR execution? You cannot with newbus. discovery of $PIR happens as part of the BIOS scans, of which pci bios is one. why do you need to do this? It seems like a very odd question. : 2. I need to call bus_alloc_resource() to get access to some io ports. : However, calling BUS_READ_IVAR in the identify routine gets a bad pointer : deref. So how do I get a handle to use for allocating the IO ports : (first arg of bus_alloc_resource)? You need a device and a parent device. If you do not have one, then you must get one. : 3. It appears bus_alloc_resource() takes a range of values. If I know the : exact value to use, I request it via value, value instead of 0, ~0. : Is this correct? Yes. However, typically the parent bus identifies these resources, and the child device swallows it. The child device typically has no say in the matter. However, the foo_identify routines can set what it thinks are the right addresses. : The framework for this code is in ec_identify() and ec_attach() in : sys/dev/acpica/acpi_ec.c. This really isn't a identify routine. You must hook into other things if you want to get access early. Let's take a step back. What are you trying to do? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Mon, 14 Jul 2003, M. Warner Losh wrote: Let's take a step back. What are you trying to do? I need to install a temporary EC handler before the namespace is evaluated. This is because various other ACPI routines will call the EC before acpi_ec_attach is called (just after sio1 attach on my laptop). The way to do this (according to the ACPI 2.0 spec and Linux code) is to read the ECDT and use its values for registers and the GPE bit until the proper attach routine is called. Here are the errors that are reported when acpica attempts to access the EC before it has been attached: acpi0: IBMTP-1Aon motherboard pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc32e2020), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc32d8160), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32da960), AE_NOT_EXIST ACPI-0175: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT0._STA] (Node 0xc32da960), AE_NOT_EXIST ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BAT1._STA] (Node 0xc32da7e0), AE_NOT_EXIST My current approach is to have a routine which is called early on (perhaps by the probe for acpi0 so it is before the $PIR enumeration). It finds the ECDT and sets up temporary mappings for the command and data registers. These registers are 8 bit IO ports (0x66 and 0x62 usually but the ECDT specifies these). I need to be able to call bus_alloc_resource() for those registers so that bus_space_read() can be used on them. So my questions basically are: 1. What's the most proper place to call the ECDT attach routine? (It's currently device_identify but that's not quite right). According to takawata-san, the best place now is acpi_attach(). That seems ok to me. 2. What's the most proper way to enable access to the command and data registers so early on, hopefully without bypassing newbus? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newbus questions
On Mon, 14 Jul 2003, Nate Lawson wrote: 3. It appears bus_alloc_resource() takes a range of values. If I know the exact value to use, I request it via value, value instead of 0, ~0. Is this correct? It's correct if you really know the values, unlike 0, ~0. The maximum value for a resource is ULONG_MAX. This is also a magic value in conjunction with a value of 0 for the start of a resource and a value of 1 for the count (see the man page). ULONG_MAX can be spelled ~0ul to abbreviate and obfuscate the code a little. ULONG_MAX can't be spelled ~0, but this is what the man page description says to use for the magic value. ~0 is -1 on 2's complement machines and -0 on 1's complement machines. It just happens to become ULONG_MAX on some machines including 2's complement ones after bogus type conversions when it is passed to bus_alloc_resource. Most drivers use the bogus version of course. The examples in the man page are correct although the description isn't. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
