problem attaching driver at LPC bus

[karu.pruun]

On Tue, Aug 23, 2016 at 6:45 PM, Ravi Pokala <rpokala at mac.com> wrote:

> -----Original Message-----
> From: <wlosh at bsdimp.com> on behalf of Warner Losh <imp at bsdimp.com>
> Date: 2016-08-23, Tuesday at 08:20
> To: Ravi Pokala <rpokala at mac.com>
> Cc: "freebsd-hackers at freebsd.org" <freebsd-hackers at freebsd.org>, <
> karu.pruun at gmail.com>
> Subject: Re: problem attaching driver at LPC bus
>
> On Tue, Aug 23, 2016 at 9:13 AM, Ravi Pokala <rpokala at mac.com> wrote:
> >> ...
> >>
> >> One thing to note is that I was careful about keeping track of the
> RIDs. Several of the existing drivers in the tree seem to just use 0
> indiscriminately, and it works because they only use one resource.
> >
> > For ISA drivers, RID is just a number, best thought of as an index.
> > So incrementing here like you've done is the right call.
> >
> > Warner
>
> Right, someone (jhb?) explained that to me at the time. My point is that
> the common practice of just passing in 0 doesn't always DTRT, especially if
> you're dealing with multiple resources.
>
> -Ravi (rpokala@)
>
>


Hi Ravi

Thanks for these suggestions. I'll study the spec and try implement this.
Question: the XXX_base in bus_set_resource --- did you find this address
from the spec? I suppose in my case this is the one I see in the acpi
tables, 0x0700.

Another question: on my naive thinking, the acpi subsystem scans the acpi
tables and populates the entries in the device tree, setting aside the
address ranges (IO and mem) for which there is no driver. The handle items
in the tree (e.g. \_SB_.PCI0.LPCB.GMUX) look very similar to the ones in
the acpi tables. So I thought the driver then later claims these resource
using the bus_alloc_resource(). Does this sound like anything that is
actually happening?

Thanks again

Peeter

--