Date: Thu, 13 Dec 2001 11:01:43 -0800 From: Mike Smith <msmith@freebsd.org> To: Thomas Moestl <tmoestl@gmx.net> Cc: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <200112131901.fBDJ1hl02003@mass.dis.org> In-Reply-To: Your message of "Thu, 13 Dec 2001 19:20:33 %2B0100." <20011213192033.A871@crow.dom2ip.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> I've attached a patch with changes I had to make to MI bus-related
> code for the sparc64 port. I would like to commit soonish (around the
> 21st) if there are no objections.
>
> The changes are in detail:
> - pass the bus device to isa_init()
> - add a generic resource list printing function, and make use of it in
> the PCI and ISA code (this may change the order in which the
> resources are printed in the ISA case).
> - add a generic __BUS_ACCESSOR macro to generate ivar accessors like
> PCI_ACCESSOR did, and make use of it in the PCI code
These are OK.
> - add a 'PCI_BROKEN_INTPIN' option. It activates a workaround for a
> bug in some Sun PCI devices, which have the intpin register wired to
> 0 although they use this interrupt generation mechanism.
This is the wrong way to do it. Fake the intpin access in the MD PCI
config space handler, and don't make it optional; if you know the device
is broken, fake it. If it's not, don't.
> - another new option, PCI_INTLINE_0_BAD, indicates that an intline
> register value of 0 is used to indicate an unrouted interrupt. It is
> required for some Sun boxes in conjunction with PCI_BROKEN_INTPIN to
> avoid the confusing detection of interrupts that are not actually
> present.
Again, fake this at the MD level.
> - make most functions in pci_pci.c non-static and add a new header
> (pcib.h) and an extension pointer to the softc to allow drivers for
> non-standard PCI-PCI bridges to use this code instead of duplicating
> most of it.
I'm not sure that non-staticising this is the correct way to go; we need
a better way of subclassing things. Without knowing what you mean by
"non-standard", it's hard to see how calling these functions is useful.
> - add a variation of rman_reserve_resource(),
> rman_reserve_resource_bound(), that can additionally honor a
> boundary for the allocation. This way, the resource manager can be
> used to handle DVMA allocations, for example.
Resource alignment should be handled above the resource manager, not in
it.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200112131901.fBDJ1hl02003>