svn commit: r197969 - head/sys/conf

[John Baldwin]

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.

-- 
John Baldwin