Subject: Re: TCPA Driver for NetBSD
To: None <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 12/10/2003 17:41:47
Content-Type: text/plain; charset=us-ascii
On Wed, Dec 10, 2003 at 04:39:50PM -0500, Rick Wash wrote:
> I've updated the patch slightly based on some comments I have received.
> The new patch is available at:
> I'd appreciate any comments you have. This patch is fairly similar to the
> previous one.
> There are a couple of questions I have regarding pci/bus_space functions,=
> I haven't been able to get the working yet.
> In particular, the TCPA chip is attached to the LPC (low-pin-count) bus on
> the motherboard, and doesn't have its own PCI ID. The driver looks for
> appropriate LPC bridge devices, and then checks that device to see if the
> TCPA chip is attached to it.
Actually, given that, what you need to implement is an LPC bus. The LPC=20
bus will attach wherever the bus interface attaches (if the bus=20
interface is a PCI device, you attach there, etc.). You then have the TCPA=
driver attach to the LPC bus.
> As such, I'm not sure if the pci_attach_args structure or the pci_conf
> BAR's contain the information that is needed to use bus_space_ routines.
> I'd like to use these routines as they are vastly better than inb/outb, b=
> I can't figure out how to map (with pci_mapreg_map(PCI_MAPREG_TYPE_IO...)=
> bus_space_map(...). I do know that this device is ONLY accessable via
> polling and i/o ports.
> Any suggestions how I can accomplish this? What information do I need to
> find in order to use these?
I'd suggest looking at the driver writing guide documentation, which I=20
think is on the NetBSD web page. I have an earlier draft around if you=20
can't find it.
You definitely need to change the driver around. There can be other things=
behind the LPC bridge. So just because you don't find a tcpa doesn't mean=
you should shut down the LPC.
I also think you need serious help with the driver to get it to configure=
right. Not because you aren't good enough, but because it looks like it=20
will tweak our config methodology.
As best I can tell from the LPC bus docs,=20
http://www.intel.com/design/chipsets/industry/25128901.pdf, they expect=20
the devices on the bus to be configured via something like ACPI. The rub=20
is that the PCI-LPC bridge chip doesn't (as best I can tell) do=20
subtractive decode; it has to be told what address ranges it should pass=20
through to the LPC bus.
So while the tcpa chip should look like an isa device with an ACPI attach=
descriptor, the LPC bridge will have to have been initialized before tcpa=
checks, as otherwise the probe will fail.
Also, I don't know if the ACPI config for the LPC bus indicates what=20
ranges it should map, or if the ACPI config for the tcpa has anything that=
indicages it is behind the LPC bus. ??
> Also, I have written man pages for the libtcpa, which are available on my
> project's site at:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----