Date: Wed, 14 Oct 2009 16:11:15 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: jhb@freebsd.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, xcllnt@mac.com, src-committers@freebsd.org Subject: Re: svn commit: r197969 - head/sys/conf Message-ID: <20091014.161115.-1796258170.imp@bsdimp.com> In-Reply-To: <200910141738.43910.jhb@freebsd.org> References: <200910141645.26010.jhb@freebsd.org> <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> <200910141738.43910.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200910141738.43910.jhb@freebsd.org>
John Baldwin <jhb@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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091014.161115.-1796258170.imp>