public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
* [Linux-ia64] ACPI 2.0 support
@ 2000-11-17 20:12 Alex Williamson
  2000-11-17 20:34 ` Mallick, Asit K
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Alex Williamson @ 2000-11-17 20:12 UTC (permalink / raw)
  To: linux-ia64

   I've been working on adding ACPI 2.0 table support for IA-64 in
preparation for McKinley systems.  I have a preliminary version
that correctly parses 2.0 tables on an architectural simulator.
I'd also like to get Intel's drop of the ACPI CA w/ 2.0 support
added into the kernel as quickly as possible.  Is there a
current maintainer of IA-64 ACPI support?  Is there anyone else
interested in working on this or testing it?

   I'd also like to incorporate using ACPI methods to get resource
information for programming PCI devices, eventually leading to
support for hot-plug PCI via ACPI.  Anyone have any thoughts or
interest there?  Thanks,

	Alex

--
Alex Williamson                                  Linux Development Lab
awilliam@fc.hp.com                                     Hewlett Packard
970-898-9173                                          Fort Collins, CO


^ permalink raw reply	[flat|nested] 4+ messages in thread

* RE: [Linux-ia64] ACPI 2.0 support
  2000-11-17 20:12 [Linux-ia64] ACPI 2.0 support Alex Williamson
@ 2000-11-17 20:34 ` Mallick, Asit K
  2000-11-18  7:52 ` Mike Smith
  2000-11-20 16:00 ` Alex Williamson
  2 siblings, 0 replies; 4+ messages in thread
From: Mallick, Asit K @ 2000-11-17 20:34 UTC (permalink / raw)
  To: linux-ia64

Intel has done the ACPI 2.0 table parsing and testing with FWs that support
ACPI 2.0 tables. We are planning to integrate this code in the next release.
These works are done primarily in preparation for McKinley systems.

Thanks,
Asit


> -----Original Message-----
> From: Alex Williamson [mailto:awilliam@fc.hp.com]
> Sent: Friday, November 17, 2000 12:12 PM
> To: linux-ia64@linuxia64.org
> Subject: [Linux-ia64] ACPI 2.0 support
> 
> 
> 
>    I've been working on adding ACPI 2.0 table support for IA-64 in
> preparation for McKinley systems.  I have a preliminary version
> that correctly parses 2.0 tables on an architectural simulator.
> I'd also like to get Intel's drop of the ACPI CA w/ 2.0 support
> added into the kernel as quickly as possible.  Is there a
> current maintainer of IA-64 ACPI support?  Is there anyone else
> interested in working on this or testing it?
> 
>    I'd also like to incorporate using ACPI methods to get resource
> information for programming PCI devices, eventually leading to
> support for hot-plug PCI via ACPI.  Anyone have any thoughts or
> interest there?  Thanks,
> 
> 	Alex
> 
> --
> Alex Williamson                                  Linux Development Lab
> awilliam@fc.hp.com                                     Hewlett Packard
> 970-898-9173                                          Fort Collins, CO
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Linux-ia64] ACPI 2.0 support
  2000-11-17 20:12 [Linux-ia64] ACPI 2.0 support Alex Williamson
  2000-11-17 20:34 ` Mallick, Asit K
@ 2000-11-18  7:52 ` Mike Smith
  2000-11-20 16:00 ` Alex Williamson
  2 siblings, 0 replies; 4+ messages in thread
From: Mike Smith @ 2000-11-18  7:52 UTC (permalink / raw)
  To: linux-ia64

>    I'd also like to incorporate using ACPI methods to get resource
> information for programming PCI devices, eventually leading to
> support for hot-plug PCI via ACPI.  Anyone have any thoughts or
> interest there?  Thanks,

I hope folks don't mind a stranger dropping in on this discussion; I've 
been doing similar work for the IA32 and IA64 FreeBSD codebase though and 
this is a point I've been looking at for a while.

The key item to bear in mind here is that ACPI stays out of the way of 
other enumeration mechanisms; meaning that ACPI itself isn't going to 
help you very much when it comes to resource information for 
newly-arrived PCI devices, other than routing interrupts for them (and 
even then your bridge driver will still have to correctly swizzle for 
devices on the other side of the bridge).

I've written (but not verified) code that uses the Intel ACPI CA codebase 
to route PCI interrupts for the host-PCI bridge; I'd be happy to furnish 
this on request, although in truth the documentation is enough to make 
this a largely trivial task.

As for allocating memory ranges and configuring intermediate bridges; 
ACPI doesn't play a role here at all (so far as I've seen, at any rate).

Hope this helps.

Mike

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Linux-ia64] ACPI 2.0 support
  2000-11-17 20:12 [Linux-ia64] ACPI 2.0 support Alex Williamson
  2000-11-17 20:34 ` Mallick, Asit K
  2000-11-18  7:52 ` Mike Smith
@ 2000-11-20 16:00 ` Alex Williamson
  2 siblings, 0 replies; 4+ messages in thread
From: Alex Williamson @ 2000-11-20 16:00 UTC (permalink / raw)
  To: linux-ia64

Mike Smith wrote:
> 
> >    I'd also like to incorporate using ACPI methods to get resource
> > information for programming PCI devices, eventually leading to
> > support for hot-plug PCI via ACPI.  Anyone have any thoughts or
> > interest there?  Thanks,
> 
> I hope folks don't mind a stranger dropping in on this discussion; I've
> been doing similar work for the IA32 and IA64 FreeBSD codebase though and
> this is a point I've been looking at for a while.
> 
> The key item to bear in mind here is that ACPI stays out of the way of
> other enumeration mechanisms; meaning that ACPI itself isn't going to
> help you very much when it comes to resource information for
> newly-arrived PCI devices, other than routing interrupts for them (and
> even then your bridge driver will still have to correctly swizzle for
> devices on the other side of the bridge).
> 
> I've written (but not verified) code that uses the Intel ACPI CA codebase
> to route PCI interrupts for the host-PCI bridge; I'd be happy to furnish
> this on request, although in truth the documentation is enough to make
> this a largely trivial task.
> 
> As for allocating memory ranges and configuring intermediate bridges;
> ACPI doesn't play a role here at all (so far as I've seen, at any rate).
> 

   Not yet ;)  They key thing to remember here is that the resources
available to a PCI bus are typically static, even if PCI devices can be
inserted and removed.  So, the _CRS/_PRS methods should be able to
provide the necessary resource information for newly inserted PCI
devices.  This will, of course, be dependent on the ACPI firmware vendor
doing a sufficient implementation and the system providing sufficient
MMIO/IO port space for added devices on each PCI bus.  If ACPI won't
work for us in determining valid PCI resources, then what chipset
independent mechanism do we have?  As we move to systems designed with
more high availability features, I see firmware playing less of a
role in actually programming the resource registers on PCI devices.
Firmware will likely lean more towards providing mechanisms by which the
OS can do it on it's own.

	Alex

--
Alex Williamson                                  Linux Development Lab
awilliam@fc.hp.com                                     Hewlett Packard
970-898-9173                                          Fort Collins, CO


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-11-20 16:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-11-17 20:12 [Linux-ia64] ACPI 2.0 support Alex Williamson
2000-11-17 20:34 ` Mallick, Asit K
2000-11-18  7:52 ` Mike Smith
2000-11-20 16:00 ` Alex Williamson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox