Date: Sat, 13 Sep 2008 03:13:27 +0100 From: Bruce M Simpson <bms@incunabulum.net> To: John Baldwin <jhb@freebsd.org> Cc: Jeremy Chadwick <koitsu@freebsd.org>, FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: alpm(4) I/O range is claimed by ACPI Message-ID: <48CB21C7.9050706@incunabulum.net> In-Reply-To: <200809111043.18265.jhb@freebsd.org> References: <48C8F684.8090409@incunabulum.net> <20080911110407.GC25493@icarus.home.lan> <48C927D6.5020800@incunabulum.net> <200809111043.18265.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:
> Umm, ACPI will allow children devices to allocate their resources out of
> the "sysresource" pool. IPMI has to do this on some systems where ACPI
> claims the IPMI I/O ports as a system resource.
But surely if alpm(4) were to attach to such a range in this way, it
would need to be a child of the acpi bus device, yes? The IPMI driver
probes for a specific ACPI ID in the DSDT.
PCI ID looks like this:
alpm0@pci0:0:30:1: class=0x068000 card=0x81561043 chip=0x710110b9
rev=0x00 hdr=0x00
So I grabbed the M1543 datasheet off the web and looked in CSR space.
Guess what: the AMI BIOS on the ASUS Vintage AH-1 does NOT set up the
PMU. The function is still visible, it just has no active I/O mappings.
No wonder alpm(4) does not attach.
I tried looking for this device in the DSDT, I don't see anything which
obviously resembles it. The equivalent Linux driver has a means of
forcing the mapping to be set up if it isn't available:
http://www.kernel.org/doc/Documentation/i2c/busses/i2c-ali15x3
It looks like there used to be a means of doing this in the FreeBSD
driver but it got nuked. And that ASUS didn't much care about power
management support in this machine...
Oh well! I know ichsmb works on at least one machine that I have.
cheers
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48CB21C7.9050706>