Date: Thu, 13 Dec 2001 21:15:44 +0100 From: Thomas Moestl <tmoestl@gmx.net> To: arch@FreeBSD.org Subject: Re: Please review: changes to MI bus code for sparc64 Message-ID: <20011213211544.A4747@crow.dom2ip.de> References: <20011213192033.A871@crow.dom2ip.de> <200112131901.fBDJ1hl02003@mass.dis.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2001/12/13 at 11:01:43 -0800, Mike Smith wrote: > > - 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. I did this in the PCI code since it is a flake of the device, so I think it does not really belong into the MD code (I know that the particular device I am seeing this with is also used in PowerPC in a different version; maybe this version is broken there in a similar way). In any case, it is better to identify these devices and add a quirk table for them than using an option, as you say. I will change that. > > - 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. I did do it in the MI code because this breakage seems to exist on many architectures, but you are right, I will change that. > > - 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. It does not have base and limit registers, the decoded range is set differently. To be able to check allocations for in-rangeness, I need to override the alloc_resource method, and of course the probe and attach methods. I can however use pcib_read_ivar, pcib_write_ivar, pcib_maxslots, pcib_read_config and pcib_write_config. This could for example also be handled by introducing a common bridge layer with the common methods and making all bridge drivers children of it and passing the other method calls through, but I don't really like that. When the next non-standard bridge comes along, the common layer would probably need to be reduced, and so on, until it maybe is not existent any more. It could of course also be done by duplicating the code in question, which I also don't really like to do. > > - 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. I'm not sure how this is meant. As I wrote, I am using it to manage virtual DVMA memory, so I need to be able to allocate resources with given alignment and boundary (to implement the busdma interface). Specifying an alignment is already supported. The only method to enforce a boundary at a higher level I could think of would be to try to adjust the allocation, which would be a gross hack. - thomas 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?20011213211544.A4747>