option NEW_PCIB

[Warner Losh]

On Mar 10, 2014, at 7:45 AM, John Baldwin <jhb at freebsd.org> wrote:

> On Friday, March 07, 2014 9:38:33 am Warner Losh wrote:
>> 
>> On Mar 7, 2014, at 6:52 AM, Ian Lepore <ian at FreeBSD.org> wrote:
>> 
>>> Every architecture has "option NEW_PCIB" in its conf/DEFAULTS except arm
>>> and mips.  Is that on purpose?  What are the implications of adding it?
>>> Or maybe more importantly, what are the implications of it not being
>>> there?
>> 
>> This is John Baldwin’s option for his reworked PCI bridge code. He did that as
>> a fallback in case he really messed up something. It introduces renumbering
>> of busses that don’t already have numbers assigned. It should be enabled on
>> ARM, but the required resource isn’t defined on arm, and some of the other
>> required glue doesn’t seem to be implemented for arm yet, which is why things
>> are the way they are at the moment. I think John intends for the option to go
>> away, and everything it covers will be ‘standard’.
> 
> Yes.  I just added a page on the wiki about NEW_PCIB explaining the changes
> each platform needs for it in a bit more detail on Friday:
> 
>   https://wiki.freebsd.org/NEW_PCIB
> 
> I have posted patches in the past to arm@ to handle step 2 in the NEW_PCIB
> base requirements for arm@ but haven't been able to get folks to test them.
> I just recently made a new pass through sys/arm in a p4 tree to refresh this.
> I haven't even compiled these yet, but you can find the patch here:
> 
>   http://people.freebsd.org/~jhb/patches/arm_activate2.patch

I’ll take a look… Thanks for putting these together...

> I don't know how best to think about fixing i80321_pci to work with NEW_PCIB.
> It has some hack that I don't fully understand.  I think it uses an
> alternate mapping of the same resource range to use a different base address
> for the mapping.  Longer term I think the bus_map_resource() think I suggest
> at the bottom is how to handle that, but even then there would still need to
> be a way to know which base address a given resource wanted to use.  It may
> be that we need to implement that differently (bus-specific rman flag?)

While I’m not normally a big fan of retiring code, I think in this case it may be easier to
just retire the i80321 support. It is really old, released in 2002. There’s not too many
boards that had this on it, and I think all the ones that ever ran FreeBSD are in cognet@‘s
lab. On the whole, it is yet another machine to update that slows down any modernization
processes we have...

Warner