svn commit: r197969 - head/sys/conf

[John Baldwin]

On Thursday 15 October 2009 10:59:10 am M. Warner Losh wrote:
> 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.

It depends I think.  If the Foo bus just maps a Foo memory resource and
then sub-allocates that to satisfy ISA ranges then from bus_space's 
perspective it is just working with Foo resources.  It would never know about 
ISA nor would it need to know.

> 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.

I think we are mostly agreeing actually.  My main statement is that how
ISA memory resources are actually mapped, etc. is platform-dependent
but that different platforms may implement that support using different
means.

-- 
John Baldwin