svn commit: r197969 - head/sys/conf

[John Baldwin]

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

-- 
John Baldwin