linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "STK" <stk@nerim.net>
To: "'Jos Hulzink'" <josh@stack.nl>,
	"'linux-kernel'" <linux-kernel@vger.kernel.org>
Cc: "'Zwane Mwaikambo'" <zwane@linuxpower.ca>
Subject: RE: [RFC] How to fix MPS 1.4 + ACPI behaviour ?
Date: Mon, 12 May 2003 23:29:35 +0200	[thread overview]
Message-ID: <000b01c318cd$992f92e0$0200a8c0@QUASARLAND> (raw)
In-Reply-To: <200305122250.32897.josh@stack.nl>


For me the linux kernel should invoke the _PIC method with the right
parameter.

Look at the specification Section 

<< ================ Start ================
5.8.1 _PIC Method
The \_PIC optional method is to report to the BIOS the current interrupt
model used by the OS. This
control method returns nothing. The argument passed into the method
signifies the interrupt model OSPM
has chosen, PIC mode, APIC mode, or SAPIC mode. Notice that calling this
method is optional for OSPM.
If the method is never called, the BIOS must assume PIC mode. It is
important that the BIOS save the value
passed in by OSPM for later use during wake operations.
_PIC(x):
_PIC(0) => PIC Mode
_PIC(1) => APIC Mode
_PIC(2) => SAPIC Mode
_PIC(3-n) => Reserved

==================== End ====================>

==> No MADT table, so ACPI sets up the APIC in PIC mode (which I wonder
wether correct, but ok)
For me the kernel should invoke the _PIC method with the right
parameter, in this case the ACPI module will receive the right table
during the _PRT

Bios ASL code:
                Method(_PRT)
                {
                If(\PICF) <== internal variable set by _PIC
                {   
                	==> Returning APIC Mode
                	Return(APIC)
                }
                Else 
                {
                	==> Returning PIC Mode
                	Return(PICM)
                }
			}

Regards,

Yann


-----Original Message-----
From: Jos Hulzink [mailto:josh@stack.nl] 
Sent: lundi 12 mai 2003 22:51
To: STK; 'linux-kernel'
Cc: 'Zwane Mwaikambo'
Subject: Re: [RFC] How to fix MPS 1.4 + ACPI behaviour ?


On Monday 12 May 2003 22:40, STK wrote:
> Hi,
>
> If no Multiple APIC Description Table (MADT) is described, in this
> case the _PIC method can be used to tell the bios to return the right 
> table (PIC or APIC routing table).
>
> In this case, if the MPS table describes matches the ACPI APIC table
> (this is the case, because the ACPI APIC table is built from the MPS 
> table), you do not need to remap all IRQs.

So, it's more or less a bug in the ACPI code that should do some things
when 
no MADT is dectected ? Or do I understand you wrong ?

Jos



  reply	other threads:[~2003-05-12 21:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-12 19:35 [RFC] How to fix MPS 1.4 + ACPI behaviour ? Jos Hulzink
2003-05-12 20:40 ` STK
2003-05-12 20:50   ` Jos Hulzink
2003-05-12 21:29     ` STK [this message]
2003-05-13  7:50       ` Zwane Mwaikambo
2003-05-13  8:54       ` Jos Hulzink
2003-05-13  5:01 ` Jurriaan
2003-05-13  7:15   ` Jos Hulzink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000b01c318cd$992f92e0$0200a8c0@QUASARLAND' \
    --to=stk@nerim.net \
    --cc=josh@stack.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zwane@linuxpower.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).