From owner-svn-src-head@FreeBSD.ORG Thu Oct 15 12:45:00 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B639106566B; Thu, 15 Oct 2009 12:45:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3D8328FC17; Thu, 15 Oct 2009 12:45:00 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E047046B2D; Thu, 15 Oct 2009 08:44:59 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 24C228A01F; Thu, 15 Oct 2009 08:44:59 -0400 (EDT) From: John Baldwin To: "M. Warner Losh" Date: Thu, 15 Oct 2009 08:33:53 -0400 User-Agent: KMail/1.9.7 References: <200910141645.26010.jhb@freebsd.org> <200910141738.43910.jhb@freebsd.org> <20091014.161115.-1796258170.imp@bsdimp.com> In-Reply-To: <20091014.161115.-1796258170.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910150833.54252.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 15 Oct 2009 08:44:59 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 12:45:00 -0000 On Wednesday 14 October 2009 6:11:15 pm M. Warner Losh wrote: > In message: <200910141738.43910.jhb@freebsd.org> > John Baldwin 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