From owner-svn-src-head@FreeBSD.ORG Wed Oct 14 21:38:50 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 E23D3106566B; Wed, 14 Oct 2009 21:38:49 +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 9EBBB8FC17; Wed, 14 Oct 2009 21:38:49 +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 31D6C46B0C; Wed, 14 Oct 2009 17:38:49 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8CBAE8A01B; Wed, 14 Oct 2009 17:38:48 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Date: Wed, 14 Oct 2009 17:38:43 -0400 User-Agent: KMail/1.9.7 References: <200910141645.26010.jhb@freebsd.org> <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> In-Reply-To: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910141738.43910.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 14 Oct 2009 17:38:48 -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, src-committers@freebsd.org, Warner Losh 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: Wed, 14 Oct 2009 21:38:50 -0000 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