svn commit: r197969 - head/sys/conf

[M. Warner Losh]

In message: <200910150833.54252.jhb at freebsd.org>
            John Baldwin <jhb at freebsd.org> writes:
: On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote:
: > In message: <200910141738.43910.jhb at freebsd.org>
: >             John Baldwin <jhb at freebsd.org> writes:
: > : On Wednesday 14 October 2009 5:20:38 pm Marcel Moolenaar wrote:
: > : > 
: > : > On Oct 14, 2009, at 1:45 PM, John Baldwin wrote:
: > : > 
: > : > > On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote:
: > : > >> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote:
: > : > >>>
: > : > >>> I can't be more clear than this.  You keep ignoring me, and it is  
: > : > >>> very
: > : > >>> frustrating.
: > : > >>
: > : > >> I'm not ignoring you. I'm still talking. You simply haven't convinced
: > : > >> me. While it's possible (likely?) that I don't understand the issues,
: > : > >> all you've achieved so far is that I'm more convinced that limiting
: > : > >> orm(4) to i386 and amd64 is the right thing, because the alternative
: > : > >> is not at all appealing.
: > : > >>
: > : > >>> The problem is that the
: > : > >>> powerpc and itanium isa modules allow memory ranges that shouldn't  
: > : > >>> be
: > : > >>> allowed.  That's the platform specific code that needs to be fixed.
: > : > >>
: > : > >> isa_set_resource() is MI code and it happily adds whatever resources
: > : > >> a driver wants. The only chance MD code has is to fail the  
: > : > >> allocation,
: > : > >> but since the whole ISA code bypasses the newbus hierarchy, there's
: > : > >> no way we know in the isa MD code what is valid and what isn't unless
: > : > >> we add kluges to platform code.
: > : > >>
: > : > >> If you want to fix it for real, does that mean fix it for real or
: > : > >> does that mean add kluges to platform code?
: > : > >>
: > : > >> Shouldn't we have ISA bridges obtain the set of valid resources
: > : > >> from their parent in the newbus hierarchy?
: > : > >
: > : > > Hmm, can we even know that?  PCI-ISA bridges in x86 at least don't  
: > : > > have any
: > : > > I/O limit registers like PCI-PCI bridges, instead they are  
: > : > > subtractively
: > : > > decoded, i.e. they "eat" any memory request that no one else claims.
: > : > 
: > : > The key here being requests that reach the PCI-ISA bridge. It's entirely
: > : > platform specific which I/O memory addresses generated by the CPU gets
: > : > decoded and forwarded in such a way that it's visible to the PCI-ISA
: > : > bridge. This is what needs to be obtained from the parent in the newbus
: > : > hierarchy. Rather than hardcoding [0xC0000 .. 0x100000> as the ISA  
: > : > option
: > : > ROM memory range, it should be something like [isa_mem_base+0xC0000 ..
: > : > isa_mem_base + 0x100000> or even [isa_rom_base .. isa_rom_base +  
: > : > 0x40000>.
: > : 
: > : That might certainly be a reasonable IVAR for isab(4) to provide to isa(4): a 
: > : ROM base.  However, orm(4) should be enabled for all ISA bridges assuming 
: > : that is fixed.  OTOH, the way many bus drivers I've seen handle this so far 
: > : is to change the base address of SYS_RES_MEMORY objects as they pass through 
: > : the relevant bridge so that the actual memory address is properly adjusted 
: > : when it gets to the equivalent of the nexus.  This is how many of the 
: > : Foo->PCI bridges in arm that I've looked at work, and I think this is more 
: > : inline with Warner's original patch which is to allow the various 
: > : platform-specific ISA bridge drivers reject memory ranges they do not decode 
: > : and provide any needed adjustments to ranges they do decode to transform them 
: > : into suitable resources for their parent.  Then orm(4) would just see it's 
: > : attempts to do bus_alloc_resource() fail and end up DTRT.  Given that, I do 
: > : think this logic belongs in the ISA bridge drivers rather than in individual 
: > : ISA drivers.  We don't make ISA peripheral drivers add an 'isa_mem_base' or 
: > : equivalent to their I/O resources, and in terms of I/O resources, orm(4) is 
: > : just a special blackhole device (much like the ACPI or PnPBIOS system 
: > : resource devices, or the ram0 or apic0 devices on x86).
: > 
: > This is exactly what I've been trying to say: the memory addresses
: > that orm is using are ISA BUS addresses.  These just happen to map 1:1
: > on x86, but will map to something else on other platforms.  But our
: > kernel API is that the driver requests the bus address, and that any
: > necessary translation happen in the bus_space layer.
: > 
: > I disagree that it belongs entirely in the isa bridge drivers.  They
: > may communicate information to the bus_space implementation, but it is
: > bus_space that ultimately does this translation.
: 
: I think it actually depends on the platform as to where it belongs.  If you
: have some Foo->ISA bridge that uses a window on the Foo bus to map ISA space,
: then I think it makes sense to handle that in the Foo->ISA bridge, especially
: if it is a relocatable window.  If the ISA bus is instead assigned a fixed
: range in the system address space then that probably belongs in the bus_space
: support.

I'd think it would be the opposite.  bus_space needs to know how to
map the request, since it is the last one involved.  If this is
mappable or movable, then it needs to know that too.

However, adjusting the resources that you give to a child on the way
through the bridge is just assisting bus_space doing the right thing
if the bus_space on that architecture just implements one or two
global spaces.

Warner