From owner-svn-src-all@FreeBSD.ORG Thu Jul 3 21:55:47 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 7AE033D9; Thu, 3 Jul 2014 21:55:47 +0000 (UTC) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6076528CD; Thu, 3 Jul 2014 21:55:47 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.14.9/8.14.9) with ESMTP id s63LtTP2013437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 3 Jul 2014 14:55:30 -0700 Message-ID: <53B5D151.60502@freebsd.org> Date: Thu, 03 Jul 2014 14:55:29 -0700 From: Nathan Whitehorn User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: svn commit: r268173 - head/sys/conf References: <201407021946.s62JkgHo051426@svn.freebsd.org> <53B465E0.1040309@freebsd.org> <20140702202813.GB69016@alchemy.franken.de> <53B46BF6.6040205@freebsd.org> <20140703195208.GE69016@alchemy.franken.de> In-Reply-To: <20140703195208.GE69016@alchemy.franken.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-ID: C;wJu4v/wC5BG89pBsdPQXfw== M;cJLfv/wC5BG89pBsdPQXfw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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 21:55:47 -0000 On 07/03/14 12:52, Marius Strobl wrote: > 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. fbd needs a lot of help for a lot of reasons. It doesn't work with early-boot console drivers at all, for example. The way all the fb stuff connects is a horribly tangled evil octopus, as well. You'll notice that ofwfb just ignores all of it at present. > But yes, ofwfb(4) being PCI-centric is yet another problem. > It isn't, actually, and will work perfectly well with non-PCI linear framebuffers. If the device is a PCI device, it has some hacks to work around broken firmwares. It also does some additional things in this case to set the mapping write-combining flag when you use it to mmap() physical memory (X UMS drivers do this). But I don't think SPARC supports pmap_setattr() anyway. -Nathan