Re: pchb@acpi again

[KIYOHARA Takashi <kiyohara%kk.iij4u.or.jp@localhost>]

Hi!


From: Chuck Silvers <chuq%chuq.com@localhost>
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@localhost>
> > 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