From owner-freebsd-arm@FreeBSD.ORG Sun Jan 18 20:52:35 2015 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 832B4A52 for ; Sun, 18 Jan 2015 20:52:35 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 58715D8E for ; Sun, 18 Jan 2015 20:52:34 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YCwpg-0002iI-ID; Sun, 18 Jan 2015 20:52:28 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0IKqQFI027517; Sun, 18 Jan 2015 13:52:27 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18tu7+iU+JO+YDChVqkj+GY Message-ID: <1421614346.14601.338.camel@freebsd.org> Subject: Re: HS mode in RPi From: Ian Lepore To: Daisuke Aoyama Date: Sun, 18 Jan 2015 13:52:26 -0700 In-Reply-To: <9C4B3BEE66EA4C1582F149682BBF729E@ad.peach.ne.jp> References: <9C4B3BEE66EA4C1582F149682BBF729E@ad.peach.ne.jp> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2015 20:52:35 -0000 On Sun, 2015-01-18 at 17:31 +0900, Daisuke Aoyama wrote: > I forget mention. r276985 is complete wrong. > > SDHCI_COMMAND_FLAGS is never stored in local variable. > So accessing it means "return uninitialized value". > > > if (off == SDHCI_TRANSFER_MODE) { > > return (sc->cmd_and_mode >> 16); > > } else if (off == SDHCI_COMMAND_FLAGS) { > > return (sc->cmd_and_mode & 0x0000ffff); > > } > Fixed in r277346, but nothing will actually change because nothing right now does a 16-bit read of SDHCI_COMMAND_FLAGS. But if that ever changes, now the code will work right. > Also I fixed, the code may return unexpected value. > 16bit width access should use even address. > >return ((val >> (off & 3)*8) & 0xffff); sdhci will never do a bus_space_read_2() on an odd address, so (off & 3) has the same effect as (off & 2). In general it is expected that the bus_space accessor functions will be used with offsets that are aligned to the size of the operation. The documentation doesn't absolutely forbid unaligned access, but it strongly encourages natural alignment and notes that unaligned operations may fail. -- Ian