From owner-svn-src-all@FreeBSD.ORG Thu Jul 3 19:52:11 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E52B08CF; Thu, 3 Jul 2014 19:52:11 +0000 (UTC) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "alchemy.franken.de", Issuer "alchemy.franken.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6069E2E01; Thu, 3 Jul 2014 19:52:10 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.8/8.14.8/ALCHEMY.FRANKEN.DE) with ESMTP id s63Jq8PD003458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 3 Jul 2014 21:52:08 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.8/8.14.8/Submit) id s63Jq8H5003457; Thu, 3 Jul 2014 21:52:08 +0200 (CEST) (envelope-from marius) Date: Thu, 3 Jul 2014 21:52:08 +0200 From: Marius Strobl To: Nathan Whitehorn Subject: Re: svn commit: r268173 - head/sys/conf Message-ID: <20140703195208.GE69016@alchemy.franken.de> References: <201407021946.s62JkgHo051426@svn.freebsd.org> <53B465E0.1040309@freebsd.org> <20140702202813.GB69016@alchemy.franken.de> <53B46BF6.6040205@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53B46BF6.6040205@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (alchemy.franken.de [0.0.0.0]); Thu, 03 Jul 2014 21:52:08 +0200 (CEST) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jul 2014 19:52:12 -0000 On Wed, Jul 02, 2014 at 01:30:46PM -0700, Nathan Whitehorn wrote: > > On 07/02/14 13:28, Marius Strobl wrote: > > On Wed, Jul 02, 2014 at 01:04:48PM -0700, Nathan Whitehorn wrote: > >> It worked at least on my Ultra 5 -- though probably because the ATI > >> Mach64 FCode ROM there is substantially shared with the Mac version. It > >> was even reasonably fast. But regardless of whether it's a generally > >> useful console driver on SPARC, at least it proves that vt(4) works fine. > > As for vt(4), it at least needs to be taught about the differences > > between virtual, physical and bus address with a clue bat. Among > > other problems, similar things hold for the #ifdef'ed sparc64 code > > of ofwfb(4) in combination with the accesses it does. I guess it > > only had a chance of working on your machine because its firmware > > is kind enough to map the framebuffer in (which not all machine > > models do) in the first place _and_ in a special way/location so > > accesses didn't blow. Anyway, even when going the ofwfb(4) route, > > doing reads and writes via bus_space(9) will be noticeably faster > > than going through the MMU on sparc64. > > Yeah, the firmware there is pretty kind. I just wanted to make sure we > were on the same page. The vt core does not require any changes, I > think: it's just that you need new drivers for mach64 and, especially, > creator. Well, at least dev/fb/fbd.c committed as part of vt(4) should need some fixes and enhancements to work on sparc64 when it comes to running X. But yes, ofwfb(4) being PCI-centric is yet another problem. Marius