Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 May 2004 14:00:59 -0700 (PDT)
From:      Nate Lawson <nate@root.org>
To:        Takanori Watanabe <takawata@init-main.com>
Cc:        jhb@freebsd.org
Subject:   Re: PERFORCE change 52156 for review
Message-ID:  <20040514140045.K98841@root.org>
In-Reply-To: <200405140109.i4E19Lqe024455@sana.init-main.com>
References:  <200405140109.i4E19Lqe024455@sana.init-main.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 14 May 2004, Takanori Watanabe wrote:
> In message <20040513144346.W91362@root.org>, Nate Lawson =A4=B5=A4=F3=A4=
=A4=A4=EF=A4=AF:
> >On Thu, 13 May 2004, Takanori Watanabe wrote:
> >> In message <20040512174010.L85042@root.org>, Nate Lawson wrote:
> >> >You bring up a problem that I've been having also.  When I commit the=
 ACPI
> >> >performance states driver, it needs to be able to get an ACPI handle.=
  My
> >> >solution to this is to have multiple drivers with the same name.  Onl=
y the
> >> >acpi one will supply a handle to the processor object.
> >> >legacy mode:
> >> >legacy0
> >> >        cpu0 (implemented in legacy.c)
> >> >             speedstep0
> >> >
> >> >acpi mode:
> >> >acpi0
> >> >        cpu0 (implemented in acpi_cpu.c)
> >> >             acpi_perf0
> >> >             speedstep0
> >> >
> >> >In the legacy case, acpi_perf's probe method will be called but it wi=
ll
> >> >return ENXIO because the non-acpi cpu0 will always return NULL for th=
e
> >> >ACPI_HANDLE ivar.  It's kind of lame because it requires two differen=
t
> >> >drivers to implement the same ivars but it's the only way I could fig=
ure
> >> >out to allow both non-acpi and acpi-based cpufreq drivers attach.
> >>
> >> In this case, pci1 and its children know ACPI handle, if
> >> ACPI vga extension is appeard in the name space tree.
> >> You will see this by devinfo(8) with -v option. So the
> >> role of video0 driver is manage child drivers.
> >> All request may forwarded to the grand parent.
> >
> >I guess I haven't looked closely enough at acpi_pci.c.  So it calls chil=
d
> >probe based on _ADR data in child ACPI objects via WalkNamespace?  Does =
it
> >then call normal pci config register probe for devices that don't appear
> >in the acpi namespace?
>
> Basically ACPI aware PCI devices are probed by pci config
> register as usual.(ACPI namespace does not describe enough
> information to determine drivers)
> But after adding device  has finished, walk name space and attach
> acpi handle if _ADR matches the device objects that has probed.
> Then if a PCI bridge knows ACPI handle, the PCI bridge is attached
> as ACPI-aware PCI bridge.

Thanks, that makes sense to me now.

-Nate


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040514140045.K98841>