Article View: fa.netbsd.tech.kern
Article #99Re: pchb@acpi again
From: KIYOHARA Takashi
Date: Wed, 08 May 2013 12:00
Date: Wed, 08 May 2013 12:00
99 lines
6142 bytes
6142 bytes
Hi!
From: Chuck Silvers <chuq@chuq.com>
Date: Sun, 5 May 2013 18:54:54 -0700
> On Mon, Apr 22, 2013 at 09:21:50PM +0900, KIYOHARA Takashi wrote:
> > Hi!
> >
> >
> > From: Chuck Silvers <chuq@chuq.com>
> > Date: Sun, 21 Apr 2013 08:33:24 -0700
> >
> > > On Mon, Apr 15, 2013 at 09:14:51PM +0900, KIYOHARA Takashi wrote:
> > > > > > > in acpi_pci.c, why do you need to skip the check for ACPI_VALID_ADR?
> > > > > > > does the ACPI info on ia64 not have that flag set when it should?
> > > > > >
> > > > > > In my memory, YES. :-<
> > > > > > But I can't access to my ia64 now. I will try and check at next weekend.
> > > > >
> > > > > In my ia64(zx6000), it looked that AcpiNsSearchAndEnter() returned
> > > > > AE_NOT_FOUND.
> > > > > How enable ACPI_DEBUG_PRINT or others many print?
> > > >
> > > > I look this messages on my ia64. (e.g. PCI0)
> > > >
> > > > _ADR Not found in 0xe00000003f9dd1e8 [Not adding]
> > > > Name [_ADR] not found in scope [PCI0] 0xe00000003f9dd1e8
> > > >
> > > >
> > > > I think that no this problem crops up by all ia64 machines. Do you know
> > > > the better evasion method?
> > > > # Can I fixup by acpi_md_callback()? I look and find that now.
> > >
> > > I was thinking that acpi_md_callback() was called before the code where you
> > > removed the check for ACPI_VALID_ADR, so you could have acpi_md_callback()
> > > walk through the device tree constructed by acpi_build_tree() and set
> > > ACPI_VALID_ADR on any devices where it was missing, as well as initializing
> > > ad->ad_devinfo->Address. but the check for ACPI_VALID_ADR in question is in
> > > acpi_pcidev_scan(), which is called at the end of acpi_build_tree(),
> > > so it's actually called before acpi_md_callback() is called.
> > >
> > > it happens that ad->ad_devinfo->Address will be zero if ACPI_VALID_ADR
> > > isn't set, I guess that value is actually correct on your system?
> >
> > By my ia64 machine, it cannot ensure that address of pchb is right.
> > I checked the boot log(typescript) of FreeBSD and Debian.
> > FreeBSD had returned AE_NOT_FOUND. The value of device and function
> > was not displayed in Linux.
> >
> > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.FreeBSD_ia64
> > http://ftp.netbsd.org/pub/NetBSD/misc/kiyohara/ia64/typescript.ia64.debian
>
> if you don't know the right value for ad->ad_devinfo->Address should be,
> how would you know how to set ap->ap_device and ap->ap_function?
> setting those two fields are what ad->ad_devinfo->Address is used for
> in acpi_pcidev_scan(). if you know how you should set those fields,
> then I think you should be able to just initialize ad->ad_devinfo->Address
> and set ACPI_VALID_ADR in ad->ad_devinfo->Valid.
>
> I looked at the diff you sent later, but it wasn't clear how that
> was supposed to work. could you also send the ia64 version of that
> new callback so we can see how the MI and MD parts would fit together?
I add this change to my ia64.
Index: acpi_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/arch/ia64/acpi/acpi_machdep.c,v
retrieving revision 1.6
diff -u -r1.6 acpi_machdep.c
--- acpi_machdep.c 23 Sep 2012 00:31:05 -0000 1.6
+++ acpi_machdep.c 8 May 2013 11:49:39 -0000
@@ -195,6 +195,20 @@
}
int
+acpi_node_md_callback(struct acpi_devnode *ad)
+{
+
+ if (ad->ad_devinfo->Flags & ACPI_PCI_ROOT_BRIDGE)
+ if (!(ad->ad_devinfo->Valid & ACPI_VALID_ADR)) {
+ /* Fixup no _ADR */
+ ad->ad_devinfo->Valid |= ACPI_VALID_ADR;
+ return 1;
+ }
+
+ return 0;
+}
+
+int
acpi_md_sleep(int state)
{
printf("%s: not yet...\n", __func__);
Thanks,
--
kiyohara
Technical Details
Message-ID:
<fa.aTWw7O2z7029M/XdrttWpEBMC+g@ifi.uio.no>Path:
arc1-ca.pugleaf.net!y6ni21411qax.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!news.glorb.com!uio.no!nntp.uio.no!.POSTED!not-for-mailReferences:
<fa.rGsQKoX+IRByuQ+mngLE3fAZkDA@ifi.uio.no> <fa.Xun/FJMYdz3J4kmoErCvKzZIluA@ifi.uio.no> <fa./m/FvO1XKAn5hd6hmW2KJ6l3sK0@ifi.uio.no>Show Full Headers
Complete Article Headers
X-Google-Thread: b7e13b6095,c9fc83a65eb70a5f
X-Google-Attributes: gidb7e13b6095,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.224.165.130 with SMTP id i2mr7364575qay.2.1368014424704;
Wed, 08 May 2013 05:00:24 -0700 (PDT)
Path: arc1-ca.pugleaf.net!y6ni21411qax.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!news.glorb.com!uio.no!nntp.uio.no!.POSTED!not-for-mail
From: KIYOHARA Takashi <kiyohara@kk.iij4u.or.jp>
Newsgroups: fa.netbsd.tech.kern
Subject: Re: pchb@acpi again
Date: Wed, 08 May 2013 12:00:24 UTC
Organization: Internet mailing list
Lines: 100
Sender: tech-kern-owner@NetBSD.org
Message-ID: <fa.aTWw7O2z7029M/XdrttWpEBMC+g@ifi.uio.no>
References: <fa.rGsQKoX+IRByuQ+mngLE3fAZkDA@ifi.uio.no> <fa.Xun/FJMYdz3J4kmoErCvKzZIluA@ifi.uio.no> <fa./m/FvO1XKAn5hd6hmW2KJ6l3sK0@ifi.uio.no>
NNTP-Posting-Host: mail-jess.uio.no
Mime-Version: 1.0
X-Trace: readme.uio.no 1368014424 23383 129.240.7.9 (8 May 2013 12:00:24 GMT)
X-Complaints-To: abuse@uio.no
NNTP-Posting-Date: Wed, 8 May 2013 12:00:24 +0000 (UTC)
Cc: current-users@netbsd.org, tech-kern@netbsd.org
To: chuq@chuq.com
Delivered-To: tech-kern@netbsd.org
X-Virus-Scanned: amavisd-new at NetBSD.org
Authentication-Results: mail.NetBSD.org (amavisd-new);
dkim=pass (1024-bit key) header.d=kk.iij4u.or.jp
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=kk.iij4u.or.jp;h=Date:
Message-Id:To:Cc:From:In-Reply-To:References:Mime-Version:Content-Type:
Content-Transfer-Encoding;i=kiyohara@kk.iij4u.or.jp;s=20120530.iij4u;t=
1368014350;x=1369223950;bh=utoL0AnqzktnH4hJc7Ovmf1zqsJPhiw9t6U0aB7qx34=;b=iyl
Dgr+WHnbWbcJEpDsJW+qFB7hMHeENzc1vExPR504QKahk9ER4b6BD0j9EoiP8SgEoJg9+o1WsVH0D
+tNgdKpp+Qh16PzZN8uMFFEA+rBkUU2VD5SF8tYgMr2XeZunm7dXH0MxaT/YO+mhloJNycXCpiHdm
s52RUWHrpbS5W0=;
In-Reply-To: <20130506015454.GA29678@spathi.chuq.com>
X-Mailer: Mew version 4.2 on Emacs 20.7 / Mule 4.1 (AOI)
List-Id: tech-kern.NetBSD.org
Original-Date: Wed, 08 May 2013 20:59:02 +0900 (JST)
Original-Message-Id: <20130508.205902.127639016.kiyohara@kk.iij4u.or.jp>
Original-References: <20130421153324.GB7327@spathi.chuq.com>
<20130422.212150.118996763.kiyohara@kk.iij4u.or.jp>
<20130506015454.GA29678@spathi.chuq.com>
Bytes: 5861
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit