Date: Fri, 22 Aug 2003 12:54:02 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Perforce Change Reviews <perforce@FreeBSD.org> Subject: Re: PERFORCE change 36551 for review Message-ID: <XFMail.20030822125402.jhb@FreeBSD.org> In-Reply-To: <20030821173225.GA780@dhcp42.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21-Aug-2003 Marcel Moolenaar wrote: > On Thu, Aug 21, 2003 at 01:13:03PM -0400, John Baldwin wrote: >> >> I'd still be interested to see what the MADT output from acpidump >> is on one of these machines. > > See http://people.freebsd.org/~marcel/acpidump.txt > I just made it. Lots of IO SAPICs, and no ISA interrupts at all it seems. (iosapic 0 has intbase of 16). >> What I plan to have is an ISA bus that has a identify routine >> that uses ACPI to enumerate ISA devices defined in ACPI. > > I'm not sure I like the sound of that. We need a clear distinction > between ISA and ACPI on ia64, because not all machines have ISA > compatibility in their chipsets. It must therefore be possible to > build kernels without ISA but still have well-known devices (from > the ISA era) used as ACPI devices. > > Take for example the code in sio(4) that tries to detect which IRQ > is raised by the device. This is perfectly valid for true ISA, but > utterly and miserably fails for ACPI devices in non-ISA machines. > So, you want the ISA bus attachment to be able to detect the IRQ, > and have a seperate ACPI bus attachment that simply doesn't bother. > This means that you need an ISA bus that doesn't double for something > that isn't ISA, like ACPI. The sio(4) IRQ testing code just needs to die in general I think. Perhaps we could axe isa_irq_pending() since it is the one main MI consumer of that hack. > So, please. Do not blur the distinction by having it all mapped as > ISA devices. I really don't want to have to shoot you :-) Well, the other alternative is to add an ACPI attachment for every ISA device. I'm sure you can appreciate my lack of zeal for this option. :( Probably though, I will only create an ACPI ISA bus if an ACPI 'Generic ISA Bus Device' exists. Basically, the ACPI ISA bus driver has to attach to an 'isa' instance hung off a 'isab' somewhere. 'isab's only turn up in two places: PCI-ISA bridges or the aforementioned ACPI Generic ISA Bus Device. Hmm, your ASL does have an ISA bus in it, just no child devices, so your uart's would not be probed by it. The ACPI ISA bus would only probe descendants of the associated device in the tree. > I'll ask around. Good luck. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20030822125402.jhb>