From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 12 15:54:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F5DE15D for ; Fri, 12 Oct 2012 15:54:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 227718FC14 for ; Fri, 12 Oct 2012 15:54:58 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 864E0B9BC; Fri, 12 Oct 2012 11:54:57 -0400 (EDT) From: John Baldwin To: Carl Delsey Subject: Re: No bus_space_read_8 on x86 ? Date: Fri, 12 Oct 2012 11:31:46 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p20; KDE/4.5.5; amd64; ; ) References: <506DC574.9010300@intel.com> <201210091154.15873.jhb@freebsd.org> <5075EC29.1010907@intel.com> In-Reply-To: <5075EC29.1010907@intel.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201210121131.46373.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 12 Oct 2012 11:54:57 -0400 (EDT) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2012 15:54:58 -0000 On Wednesday, October 10, 2012 5:44:09 pm Carl Delsey wrote: > Sorry for the slow response. I was dealing with a bit of a family > emergency. Responses inline below. > > On 10/09/12 08:54, John Baldwin wrote: > > On Monday, October 08, 2012 4:59:24 pm Warner Losh wrote: > >> On Oct 5, 2012, at 10:08 AM, John Baldwin wrote: > > >>> I think cxgb* already have an implementation. For amd64 we should certainly > >>> have bus_space_*_8(), at least for SYS_RES_MEMORY. I think they should fail > >>> for SYS_RES_IOPORT. I don't think we can force a compile-time error though, > >>> would just have to return -1 on reads or some such? > > Yes. Exactly what I was thinking. > > >> I believe it was because bus reads weren't guaranteed to be atomic on i386. > >> don't know if that's still the case or a concern, but it was an intentional omission. > > True. If you are on a 32-bit system you can read the two 4 byte values and > > then build a 64-bit value. For 64-bit platforms we should offer bus_read_8() > > however. > > I believe there is still no way to perform a 64-bit read on a i386 (or > at least without messing with SSE instructions), but if you have to read > a 64-bit register, you are stuck with doing two 32-bit reads and > concatenating them. I figure we may as well provide an implementation > for those who have to do that as well as the implementation for 64-bit. I think the problem though is that the way you should glue those two 32-bit reads together is device dependent. I don't think you can provide a completely device-neutral bus_read_8() on i386. We should certainly have it on 64-bit platforms, but I think drivers that want to work on 32-bit platforms need to explicitly merge the two words themselves. -- John Baldwin