From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 08:22:34 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5D948106564A; Sun, 19 Aug 2012 08:22:34 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 52B6D8FC0A; Sun, 19 Aug 2012 08:22:32 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q7J8MEtc038989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Aug 2012 17:22:24 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q7J8MDZ6008598; Sun, 19 Aug 2012 17:22:14 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 19 Aug 2012 17:17:23 +0900 (JST) Message-Id: <20120819.171723.523519054460575158.hrs@allbsd.org> To: gonzo@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Aug_19_17_17_23_2012_120)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 19 Aug 2012 17:22:25 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT, SAMEHELOBY2HOP, USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-arm@FreeBSD.org Subject: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 08:22:34 -0000 ----Security_Multipart0(Sun_Aug_19_17_17_23_2012_120)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Aug_19_17_17_23_2012_889)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Aug_19_17_17_23_2012_889)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, Can you review the attached patches? The first one is to add >32 pins support for hint.devname.%d.pins and pin_getname method into gpiobus similar to gpio interface. After applying this, the following hint will be supported: hint.gpioled.0.at="gpiobus0" hint.gpioled.0.pins0="0x00000000" # 41 hint.gpioled.0.pins1="0x00000200" hint.gpioled.0.pins can still be used when the pin number is lower than 32. The addition of pin_getname method is to reuse pin name if it is already defined in the parent gpio driver. The maximum of the pin number is limited by GPIOBUS_PINS_MAX (currently 128). Another one is a simple GPIO-sysctl bridge driver. Currently it supports read operation only, but it is easy to add write one. I confirmed if the both work fine by using several Marvell 88F628[12]-based boards. -- Hiroki ----Next_Part(Sun_Aug_19_17_17_23_2012_889)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gpiobus-20120819-1.diff" Index: sys/dev/gpio/gpiobus.c =================================================================== --- sys/dev/gpio/gpiobus.c (revision 239381) +++ sys/dev/gpio/gpiobus.c (working copy) @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -47,7 +48,7 @@ #include "gpiobus_if.h" static void gpiobus_print_pins(struct gpiobus_ivar *); -static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); +static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int *, size_t); static int gpiobus_probe(device_t); static int gpiobus_attach(device_t); static int gpiobus_detach(device_t); @@ -69,6 +70,7 @@ static int gpiobus_pin_setflags(device_t, device_t, uint32_t, uint32_t); static int gpiobus_pin_getflags(device_t, device_t, uint32_t, uint32_t*); static int gpiobus_pin_getcaps(device_t, device_t, uint32_t, uint32_t*); +static int gpiobus_pin_getname(device_t, device_t, uint32_t, char *); static int gpiobus_pin_set(device_t, device_t, uint32_t, unsigned int); static int gpiobus_pin_get(device_t, device_t, uint32_t, unsigned int*); static int gpiobus_pin_toggle(device_t, device_t, uint32_t); @@ -119,15 +121,18 @@ } static int -gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int mask) +gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int *mask, + size_t masklen) { struct gpiobus_ivar *devi = GPIOBUS_IVAR(child); - int i, npins; + int i, j, pin, npins; npins = 0; - for (i = 0; i < 32; i++) { - if (mask & (1 << i)) - npins++; + for (i = 0; i < masklen; i++) { + for (j = 0; j < sizeof(mask[i]) * 8; j++) { + if (mask[i] & (1 << j)) + npins++; + } } if (npins == 0) { @@ -143,27 +148,30 @@ return (ENOMEM); npins = 0; - for (i = 0; i < 32; i++) { + for (i = 0; i < masklen; i++) { + for (j = 0; j < sizeof(mask[i]) * 8; j++) { + if ((mask[i] & (1 << j)) == 0) + continue; - if ((mask & (1 << i)) == 0) - continue; - - if (i >= sc->sc_npins) { - device_printf(child, - "invalid pin %d, max: %d\n", i, sc->sc_npins - 1); - return (EINVAL); + pin = i * sizeof(mask[i]) * 8 + j; + if (pin >= sc->sc_npins) { + device_printf(child, + "invalid pin %d, max: %d\n", pin, + sc->sc_npins - 1); + return (EINVAL); + } + devi->pins[npins++] = pin; + /* + * Mark pin as mapped and give warning if it's + * already mapped + */ + if (sc->sc_pins_mapped[pin]) { + device_printf(child, + "warning: pin %d is already mapped\n", pin); + return (EINVAL); + } + sc->sc_pins_mapped[pin] = 1; } - - devi->pins[npins++] = i; - /* - * Mark pin as mapped and give warning if it's already mapped - */ - if (sc->sc_pins_mapped[i]) { - device_printf(child, - "warning: pin %d is already mapped\n", i); - return (EINVAL); - } - sc->sc_pins_mapped[i] = 1; } return (0); @@ -192,6 +200,8 @@ * Increase to get number of pins */ sc->sc_npins++; + if (bootverbose) + device_printf(dev, "number of pins = %d\n", sc->sc_npins); KASSERT(sc->sc_npins != 0, ("GPIO device with no pins")); @@ -304,19 +314,47 @@ return (child); } +#define GPIOBUS_PINS_MAX 128 +static int pinmask[(GPIOBUS_PINS_MAX - 1) / (sizeof(int) * 8) + 1]; +static char pinresname[] = "pinsNNN"; + static void gpiobus_hinted_child(device_t bus, const char *dname, int dunit) { struct gpiobus_softc *sc = GPIOBUS_SOFTC(bus); struct gpiobus_ivar *devi; device_t child; - int pins; + int i, error; + bzero((char *)&pinmask, sizeof(pinmask)); child = BUS_ADD_CHILD(bus, 0, dname, dunit); devi = GPIOBUS_IVAR(child); - resource_int_value(dname, dunit, "pins", &pins); - if (gpiobus_parse_pins(sc, child, pins)) + if (resource_int_value(dname, dunit, "pins", &pinmask[0]) == 0) { + /* + * Backward compatibility for 32-pin configuration in a + * 32-bit hint: + * + * hint.devname.%d.pins=0x00000000 + */ + i = 1; + } else { + /* + * A 32-bit hint configures a 32-pin block: + * + * hint.devname.%d.pins0=0x00000000 # 0..31 + * hint.devname.%d.pins1=0x00000000 # 32..63 + * hint.devname.%d.pins2=0x00000000 # 64..91 + */ + for (i = 0; i < sizeof(pinmask)/sizeof(pinmask[0]); i++) { + snprintf(pinresname, sizeof(pinresname), "pins%d", i); + error = resource_int_value(dname, dunit, pinresname, + &pinmask[i]); + if (error) + break; + } + } + if (gpiobus_parse_pins(sc, child, pinmask, i)) device_delete_child(bus, child); } @@ -409,6 +447,18 @@ } static int +gpiobus_pin_getname(device_t dev, device_t child, uint32_t pin, char *name) +{ + struct gpiobus_softc *sc = GPIOBUS_SOFTC(dev); + struct gpiobus_ivar *devi = GPIOBUS_IVAR(child); + + if (pin >= devi->npins) + return (EINVAL); + + return GPIO_PIN_GETNAME(sc->sc_dev, devi->pins[pin], name); +} + +static int gpiobus_pin_set(device_t dev, device_t child, uint32_t pin, unsigned int value) { @@ -469,6 +519,7 @@ DEVMETHOD(gpiobus_release_bus, gpiobus_release_bus), DEVMETHOD(gpiobus_pin_getflags, gpiobus_pin_getflags), DEVMETHOD(gpiobus_pin_getcaps, gpiobus_pin_getcaps), + DEVMETHOD(gpiobus_pin_getname, gpiobus_pin_getname), DEVMETHOD(gpiobus_pin_setflags, gpiobus_pin_setflags), DEVMETHOD(gpiobus_pin_get, gpiobus_pin_get), DEVMETHOD(gpiobus_pin_set, gpiobus_pin_set), Index: sys/dev/gpio/gpiobus_if.m =================================================================== --- sys/dev/gpio/gpiobus_if.m (revision 239381) +++ sys/dev/gpio/gpiobus_if.m (working copy) @@ -111,6 +111,16 @@ }; # +# Get pin name +# +METHOD int pin_getname { + device_t dev; + device_t child; + uint32_t pin_num; + char *name; +}; + +# # Set current configuration and capabilities # METHOD int pin_setflags { Index: sys/dev/gpio/gpioled.c =================================================================== --- sys/dev/gpio/gpioled.c (revision 239381) +++ sys/dev/gpio/gpioled.c (working copy) @@ -94,20 +94,25 @@ { struct gpioled_softc *sc; const char *name; + char nbuf[GPIOMAXNAME]; sc = device_get_softc(dev); sc->sc_dev = dev; sc->sc_busdev = device_get_parent(dev); GPIOLED_LOCK_INIT(sc); if (resource_string_value(device_get_name(dev), - device_get_unit(dev), "name", &name)) - name = NULL; - + device_get_unit(dev), "name", &name) != 0) { + GPIOBUS_PIN_GETNAME(sc->sc_busdev, sc->sc_dev, 0, nbuf); + nbuf[sizeof(nbuf) - 1] = '\0'; + if (nbuf[0] != '\0') + name = nbuf; + else + name = device_get_nameunit(dev); + } GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, GPIOLED_PIN, GPIO_PIN_OUTPUT); - sc->sc_leddev = led_create(gpioled_control, sc, name ? name : - device_get_nameunit(dev)); + sc->sc_leddev = led_create(gpioled_control, sc, name); return (0); } ----Next_Part(Sun_Aug_19_17_17_23_2012_889)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gpiosysctl-20120819-1.diff" Index: sys/conf/files =================================================================== --- sys/conf/files (revision 239381) +++ sys/conf/files (working copy) @@ -1268,6 +1268,7 @@ dependency "gpio_if.h" dev/gpio/gpioiic.c optional gpioiic dev/gpio/gpioled.c optional gpioled +dev/gpio/gpiosysctl.c optional gpiosysctl dev/gpio/gpio_if.m optional gpio dev/gpio/gpiobus_if.m optional gpio dev/hatm/if_hatm.c optional hatm pci Index: sys/dev/gpio/gpiosysctl.c =================================================================== --- sys/dev/gpio/gpiosysctl.c (revision 0) +++ sys/dev/gpio/gpiosysctl.c (working copy) @@ -0,0 +1,197 @@ +/*- + * Copyright (c) 2012 Hiroki Sato + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include + +#include "gpio_if.h" +#include "gpiobus_if.h" + +struct gpiosysctl_softc +{ + device_t sc_dev; + device_t sc_busdev; + struct mtx sc_mtx; +}; + +#define GPIO_SYSCTL_DEVNAME "gpiosysctl" +#define GPIO_SYSCTL_LOCK(sc) mtx_lock(&(sc)->sc_mtx) +#define GPIO_SYSCTL_UNLOCK(sc) mtx_unlock(&(sc)->sc_mtx) +#define GPIO_SYSCTL_LOCK_INIT(sc) mtx_init(&(sc)->sc_mtx, \ + device_get_nameunit((sc)->sc_dev), \ + GPIO_SYSCTL_DEVNAME, MTX_DEF) +#define GPIO_SYSCTL_LOCK_DESTROY(sc) mtx_destroy(&(sc)->sc_mtx) + +static int gs_probe(device_t); +static int gs_attach(device_t); +static int gs_detach(device_t); + +static int +gs_probe(device_t dev) +{ + + device_set_desc(dev, "GPIO-sysctl bridge driver"); + + return (0); +} + +static int +gs_gpio_in(struct gpiosysctl_softc *sc) +{ + int val; + + GPIO_SYSCTL_LOCK(sc); + GPIOBUS_LOCK_BUS(sc->sc_busdev); + GPIOBUS_ACQUIRE_BUS(sc->sc_busdev, sc->sc_dev); + GPIOBUS_PIN_GET(sc->sc_busdev, sc->sc_dev, 0, &val); + GPIOBUS_RELEASE_BUS(sc->sc_busdev, sc->sc_dev); + GPIOBUS_UNLOCK_BUS(sc->sc_busdev); + GPIO_SYSCTL_UNLOCK(sc); + + return (val); +} + +static void +gs_gpio_out(struct gpiosysctl_softc *sc, int val) +{ + GPIO_SYSCTL_LOCK(sc); + GPIOBUS_LOCK_BUS(sc->sc_busdev); + GPIOBUS_ACQUIRE_BUS(sc->sc_busdev, sc->sc_dev); + GPIOBUS_PIN_SET(sc->sc_busdev, sc->sc_dev, 0, + (val == 0) ? GPIO_PIN_LOW : GPIO_PIN_HIGH); + GPIOBUS_RELEASE_BUS(sc->sc_busdev, sc->sc_dev); + GPIOBUS_UNLOCK_BUS(sc->sc_busdev); + GPIO_SYSCTL_UNLOCK(sc); +} + +static int +gs_sysctl_handler(SYSCTL_HANDLER_ARGS) +{ + device_t dev; + struct gpiosysctl_softc *sc; + int val, ret; + + dev = (device_t)arg1; + sc = device_get_softc(dev); + if (req->newptr == NULL) { + val = gs_gpio_in(sc); + ret = sysctl_handle_int(oidp, &val, 0, req); + } else { + ret = sysctl_handle_int(oidp, &val, 0, req); + if (ret < 0 || ret > 1) { + device_printf(dev, "%d: invalid value.\n", ret); + ret = 0; + } + gs_gpio_out(sc, val); + ret = val; + } + + return (ret); +} + +static int +gs_attach(device_t dev) +{ + struct gpiosysctl_softc *sc; + struct sysctl_ctx_list *ctx; + struct sysctl_oid *oid; + device_t pdev; + const char *name; + char nbuf[GPIOMAXNAME]; + int flags; + + sc = device_get_softc(dev); + sc->sc_dev = dev; + sc->sc_busdev = device_get_parent(dev); + GPIO_SYSCTL_LOCK_INIT(sc); + + if (resource_string_value(device_get_name(dev), device_get_unit(dev), + "name", &name) != 0) { + GPIOBUS_PIN_GETNAME(sc->sc_busdev, sc->sc_dev, 0, nbuf); + nbuf[sizeof(nbuf) - 1] = '\0'; + if (nbuf[0] != '\0') + name = nbuf; + else { + device_printf(dev, "no valid name.\n"); + return (ENXIO); + } + } + ctx = device_get_sysctl_ctx(dev); + + pdev = device_get_parent(dev); + oid = device_get_sysctl_tree(pdev); + flags = CTLTYPE_INT | CTLFLAG_RD; + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(oid), OID_AUTO, name, flags, dev, + 0, gs_sysctl_handler, "I", NULL); + + return (0); +} + +static int +gs_detach(device_t dev) +{ + struct gpiosysctl_softc *sc; + + sc = device_get_softc(dev); + GPIO_SYSCTL_LOCK_DESTROY(sc); + + return (0); +} + +static devclass_t gs_devclass; + +static device_method_t gs_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, gs_probe), + DEVMETHOD(device_attach, gs_attach), + DEVMETHOD(device_detach, gs_detach), + { 0, 0 }, +}; + +static driver_t gs_driver = { + GPIO_SYSCTL_DEVNAME, + gs_methods, + sizeof(struct gpiosysctl_softc), +}; + +DRIVER_MODULE(gpiosysctl, gpiobus, gs_driver, gs_devclass, 0, 0); +MODULE_VERSION(gpiosysctl, 1); ----Next_Part(Sun_Aug_19_17_17_23_2012_889)---- ----Security_Multipart0(Sun_Aug_19_17_17_23_2012_120)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlAwoRMACgkQTyzT2CeTzy2ipwCgxfULT0udetgUXhdPkrcGxOFY /MgAnRo+muFwVMIbiGA+kBXwswBYLiJQ =PkE4 -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Aug_19_17_17_23_2012_120)---- From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 15:39:00 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1C15106566C for ; Sun, 19 Aug 2012 15:39:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E00D8FC12 for ; Sun, 19 Aug 2012 15:39:00 +0000 (UTC) Received: by ialo14 with SMTP id o14so2436897ial.13 for ; Sun, 19 Aug 2012 08:38:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Ok6iO6u4LbVw+qDyq5s0gFn//GEreszPmMN8R0zSJvY=; b=gawm8oBY/oEPJajVtESzNhvEqvt8jhACtnSCXfz7oxM9/lB1+mMvZ/hblohBsKRynt 7/0WZwQHld5j7OB6PmAM/pq5HOg0VU2JNRfLuo/r4W0lE62Ve2/pAI8Ul6W9Wpt4lIQV JTRQS9fW/2LNahysPlpMJENG3LJLzx/Oj9/dx/x2IiZdrnB/O6dtVvchn5Nff37UJNK7 IXZD+hbOypuZLpMBIPzKhjeaEe46lMpXpJbXW+ZU83LuaWYqqCs6JouXkvOzrXH8lh3Y MA8DVTIvh7hjzTxcbL8hxegn3dJy7xsdVSHyvFCtT3QeEMb/BQOEAAFOjFnju5ejwTC+ Of9w== Received: by 10.50.188.130 with SMTP id ga2mr7406128igc.32.1345390739627; Sun, 19 Aug 2012 08:38:59 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id pp4sm20611533igb.5.2012.08.19.08.38.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 08:38:58 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20120819.171723.523519054460575158.hrs@allbsd.org> Date: Sun, 19 Aug 2012 09:38:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmMsQat+sW4RBhTN3uA2mNFhEJVeyrEtdCR1sDww7vsMfsKLfAsQ9G6ZGS6XEHLZPzQFscm Cc: gonzo@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 15:39:00 -0000 On Aug 19, 2012, at 2:17 AM, Hiroki Sato wrote: > Hi, Hi Sato-san, In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. > Can you review the attached patches? The first one is to add >32 pins > support for hint.devname.%d.pins and pin_getname method into gpiobus > similar to gpio interface. After applying this, the following hint > will be supported: >=20 > hint.gpioled.0.at=3D"gpiobus0" > hint.gpioled.0.pins0=3D"0x00000000" # 41 > hint.gpioled.0.pins1=3D"0x00000200" This is, at best, awkward. Why not '41' here? Why not hints.gpioled.0.pins0=3D41? In general, the gpio stuff is too mask heavy and should be more pin = oriented. We also need a more generic way to pass around all the GPIO = pins used for aux functions of embedded devices. which pin is used for = media status interrupts, write protect detection, vcc power, etc. Looks a lot like we already keep book internally in pins. > hint.gpioled.0.pins can still be used when the pin number is lower > than 32. The addition of pin_getname method is to reuse pin name if > it is already defined in the parent gpio driver. The maximum of the > pin number is limited by GPIOBUS_PINS_MAX (currently 128). >=20 > Another one is a simple GPIO-sysctl bridge driver. Currently it > supports read operation only, but it is easy to add write one. I was rather hoping to recast much of the GPIO stuff so we can also = support interrupts based on pin numbers for any device in the tree. I'd = like this for a gpiokey generic interface that devices can register = button presses. How does one configure in vs out for these pins? And = how does one guard against trying to use the GPIO pins for things like = ethernet? Again, that may be beyond the scope of what you are trying to = achieve. > I confirmed if the both work fine by using several Marvell > 88F628[12]-based boards. >=20 > -- Hiroki > Index: sys/dev/gpio/gpiobus.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/gpio/gpiobus.c (revision 239381) > +++ sys/dev/gpio/gpiobus.c (working copy) > @@ -40,6 +40,7 @@ > #include > #include > #include > +#include >=20 > #include > #include > @@ -47,7 +48,7 @@ > #include "gpiobus_if.h" >=20 > static void gpiobus_print_pins(struct gpiobus_ivar *); > -static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); > +static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int = *, size_t); > static int gpiobus_probe(device_t); > static int gpiobus_attach(device_t); > static int gpiobus_detach(device_t); > @@ -69,6 +70,7 @@ > static int gpiobus_pin_setflags(device_t, device_t, uint32_t, = uint32_t); > static int gpiobus_pin_getflags(device_t, device_t, uint32_t, = uint32_t*); > static int gpiobus_pin_getcaps(device_t, device_t, uint32_t, = uint32_t*); > +static int gpiobus_pin_getname(device_t, device_t, uint32_t, char *); > static int gpiobus_pin_set(device_t, device_t, uint32_t, unsigned = int); > static int gpiobus_pin_get(device_t, device_t, uint32_t, unsigned = int*); > static int gpiobus_pin_toggle(device_t, device_t, uint32_t); > @@ -119,15 +121,18 @@ > } >=20 > static int > -gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int = mask) > +gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int = *mask, > + size_t masklen) I'd be tempted to adapt a different specification method for > 32bit = devices. But that may be beyond the scope of what you are trying to do. Might not be bad to document the args, but that, sadly, doesn't follow = the rest of the file... > { > struct gpiobus_ivar *devi =3D GPIOBUS_IVAR(child); > - int i, npins; > + int i, j, pin, npins; >=20 > npins =3D 0; > - for (i =3D 0; i < 32; i++) { > - if (mask & (1 << i)) > - npins++; > + for (i =3D 0; i < masklen; i++) { > + for (j =3D 0; j < sizeof(mask[i]) * 8; j++) { > + if (mask[i] & (1 << j)) > + npins++; > + } > } >=20 > if (npins =3D=3D 0) { > @@ -143,27 +148,30 @@ > return (ENOMEM); >=20 > npins =3D 0; > - for (i =3D 0; i < 32; i++) { > + for (i =3D 0; i < masklen; i++) { > + for (j =3D 0; j < sizeof(mask[i]) * 8; j++) { > + if ((mask[i] & (1 << j)) =3D=3D 0) > + continue; >=20 > - if ((mask & (1 << i)) =3D=3D 0) > - continue; > - > - if (i >=3D sc->sc_npins) { > - device_printf(child, > - "invalid pin %d, max: %d\n", i, sc->sc_npins = - 1); > - return (EINVAL); > + pin =3D i * sizeof(mask[i]) * 8 + j; > + if (pin >=3D sc->sc_npins) { > + device_printf(child, > + "invalid pin %d, max: %d\n", pin, > + sc->sc_npins - 1); > + return (EINVAL); > + } > + devi->pins[npins++] =3D pin; > + /* > + * Mark pin as mapped and give warning if it's > + * already mapped > + */ > + if (sc->sc_pins_mapped[pin]) { > + device_printf(child, > + "warning: pin %d is already = mapped\n", pin); > + return (EINVAL); > + } > + sc->sc_pins_mapped[pin] =3D 1; > } > - > - devi->pins[npins++] =3D i; > - /* > - * Mark pin as mapped and give warning if it's already = mapped > - */ > - if (sc->sc_pins_mapped[i]) { > - device_printf(child, > - "warning: pin %d is already mapped\n", i); > - return (EINVAL); > - } > - sc->sc_pins_mapped[i] =3D 1; > } >=20 > return (0); > @@ -192,6 +200,8 @@ > * Increase to get number of pins > */ > sc->sc_npins++; > + if (bootverbose) > + device_printf(dev, "number of pins =3D %d\n", = sc->sc_npins); >=20 > KASSERT(sc->sc_npins !=3D 0, ("GPIO device with no pins")); >=20 > @@ -304,19 +314,47 @@ > return (child); > } >=20 > +#define GPIOBUS_PINS_MAX 128 > +static int pinmask[(GPIOBUS_PINS_MAX - 1) / (sizeof(int) * 8) + 1]; > +static char pinresname[] =3D "pinsNNN"; > + > static void > gpiobus_hinted_child(device_t bus, const char *dname, int dunit) > { > struct gpiobus_softc *sc =3D GPIOBUS_SOFTC(bus); > struct gpiobus_ivar *devi; > device_t child; > - int pins; > + int i, error; >=20 > + bzero((char *)&pinmask, sizeof(pinmask)); >=20 > child =3D BUS_ADD_CHILD(bus, 0, dname, dunit); > devi =3D GPIOBUS_IVAR(child); > - resource_int_value(dname, dunit, "pins", &pins); > - if (gpiobus_parse_pins(sc, child, pins)) > + if (resource_int_value(dname, dunit, "pins", &pinmask[0]) =3D=3D = 0) { > + /* > + * Backward compatibility for 32-pin configuration in a > + * 32-bit hint: > + * > + * hint.devname.%d.pins=3D0x00000000 > + */ > + i =3D 1; > + } else { > + /* > + * A 32-bit hint configures a 32-pin block: > + * > + * hint.devname.%d.pins0=3D0x00000000 # 0..31 > + * hint.devname.%d.pins1=3D0x00000000 # 32..63 > + * hint.devname.%d.pins2=3D0x00000000 # 64..91 > + */ > + for (i =3D 0; i < sizeof(pinmask)/sizeof(pinmask[0]); = i++) { > + snprintf(pinresname, sizeof(pinresname), = "pins%d", i); > + error =3D resource_int_value(dname, dunit, = pinresname, > + &pinmask[i]); > + if (error) > + break; > + } > + } > + if (gpiobus_parse_pins(sc, child, pinmask, i)) > device_delete_child(bus, child); > } >=20 > @@ -409,6 +447,18 @@ > } >=20 > static int > +gpiobus_pin_getname(device_t dev, device_t child, uint32_t pin, char = *name) > +{ > + struct gpiobus_softc *sc =3D GPIOBUS_SOFTC(dev); > + struct gpiobus_ivar *devi =3D GPIOBUS_IVAR(child); > + > + if (pin >=3D devi->npins) > + return (EINVAL); > + > + return GPIO_PIN_GETNAME(sc->sc_dev, devi->pins[pin], name); > +} > + > +static int > gpiobus_pin_set(device_t dev, device_t child, uint32_t pin, > unsigned int value) > { > @@ -469,6 +519,7 @@ > DEVMETHOD(gpiobus_release_bus, gpiobus_release_bus), > DEVMETHOD(gpiobus_pin_getflags, gpiobus_pin_getflags), > DEVMETHOD(gpiobus_pin_getcaps, gpiobus_pin_getcaps), > + DEVMETHOD(gpiobus_pin_getname, gpiobus_pin_getname), > DEVMETHOD(gpiobus_pin_setflags, gpiobus_pin_setflags), > DEVMETHOD(gpiobus_pin_get, gpiobus_pin_get), > DEVMETHOD(gpiobus_pin_set, gpiobus_pin_set), > Index: sys/dev/gpio/gpiobus_if.m > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/gpio/gpiobus_if.m (revision 239381) > +++ sys/dev/gpio/gpiobus_if.m (working copy) > @@ -111,6 +111,16 @@ > }; >=20 > # > +# Get pin name > +# > +METHOD int pin_getname { > + device_t dev; > + device_t child; > + uint32_t pin_num; > + char *name; > +}; > + > +# > # Set current configuration and capabilities > # > METHOD int pin_setflags { > Index: sys/dev/gpio/gpioled.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/gpio/gpioled.c (revision 239381) > +++ sys/dev/gpio/gpioled.c (working copy) > @@ -94,20 +94,25 @@ > { > struct gpioled_softc *sc; > const char *name; > + char nbuf[GPIOMAXNAME]; >=20 > sc =3D device_get_softc(dev); > sc->sc_dev =3D dev; > sc->sc_busdev =3D device_get_parent(dev); > GPIOLED_LOCK_INIT(sc); > if (resource_string_value(device_get_name(dev), > - device_get_unit(dev), "name", &name)) > - name =3D NULL; > - > + device_get_unit(dev), "name", &name) !=3D 0) { > + GPIOBUS_PIN_GETNAME(sc->sc_busdev, sc->sc_dev, 0, nbuf); > + nbuf[sizeof(nbuf) - 1] =3D '\0'; > + if (nbuf[0] !=3D '\0') > + name =3D nbuf; > + else > + name =3D device_get_nameunit(dev); > + } > GPIOBUS_PIN_SETFLAGS(sc->sc_busdev, sc->sc_dev, GPIOLED_PIN, > GPIO_PIN_OUTPUT); >=20 > - sc->sc_leddev =3D led_create(gpioled_control, sc, name ? name : > - device_get_nameunit(dev)); > + sc->sc_leddev =3D led_create(gpioled_control, sc, name); >=20 > return (0); > } > Index: sys/conf/files > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/conf/files (revision 239381) > +++ sys/conf/files (working copy) > @@ -1268,6 +1268,7 @@ > dependency "gpio_if.h" > dev/gpio/gpioiic.c optional gpioiic > dev/gpio/gpioled.c optional gpioled > +dev/gpio/gpiosysctl.c optional gpiosysctl > dev/gpio/gpio_if.m optional gpio > dev/gpio/gpiobus_if.m optional gpio > dev/hatm/if_hatm.c optional hatm pci > Index: sys/dev/gpio/gpiosysctl.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- sys/dev/gpio/gpiosysctl.c (revision 0) > +++ sys/dev/gpio/gpiosysctl.c (working copy) > @@ -0,0 +1,197 @@ > +/*- > + * Copyright (c) 2012 Hiroki Sato > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above = copyright > + * notice, this list of conditions and the following disclaimer in = the > + * documentation and/or other materials provided with the = distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND > + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE > + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE > + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL > + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS > + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) > + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN = CONTRACT, STRICT > + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY > + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE = POSSIBILITY OF > + * SUCH DAMAGE. > + */ > + > +#include > +__FBSDID("$FreeBSD$"); > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > +#include > + > +#include > + > +#include "gpio_if.h" > +#include "gpiobus_if.h" > + > +struct gpiosysctl_softc > +{ > + device_t sc_dev; > + device_t sc_busdev; > + struct mtx sc_mtx; > +}; > + > +#define GPIO_SYSCTL_DEVNAME "gpiosysctl" > +#define GPIO_SYSCTL_LOCK(sc) mtx_lock(&(sc)->sc_mtx) > +#define GPIO_SYSCTL_UNLOCK(sc) = mtx_unlock(&(sc)->sc_mtx) > +#define GPIO_SYSCTL_LOCK_INIT(sc) mtx_init(&(sc)->sc_mtx, = \ > + = device_get_nameunit((sc)->sc_dev), \ > + GPIO_SYSCTL_DEVNAME, MTX_DEF) > +#define GPIO_SYSCTL_LOCK_DESTROY(sc) = mtx_destroy(&(sc)->sc_mtx) > + > +static int gs_probe(device_t); > +static int gs_attach(device_t); > +static int gs_detach(device_t); > + > +static int > +gs_probe(device_t dev) > +{ > + > + device_set_desc(dev, "GPIO-sysctl bridge driver"); > + > + return (0); > +} > + > +static int > +gs_gpio_in(struct gpiosysctl_softc *sc) > +{ > + int val; > + > + GPIO_SYSCTL_LOCK(sc); > + GPIOBUS_LOCK_BUS(sc->sc_busdev); > + GPIOBUS_ACQUIRE_BUS(sc->sc_busdev, sc->sc_dev); > + GPIOBUS_PIN_GET(sc->sc_busdev, sc->sc_dev, 0, &val); > + GPIOBUS_RELEASE_BUS(sc->sc_busdev, sc->sc_dev); > + GPIOBUS_UNLOCK_BUS(sc->sc_busdev); > + GPIO_SYSCTL_UNLOCK(sc); > + > + return (val); > +} > + > +static void > +gs_gpio_out(struct gpiosysctl_softc *sc, int val) > +{ > + GPIO_SYSCTL_LOCK(sc); > + GPIOBUS_LOCK_BUS(sc->sc_busdev); > + GPIOBUS_ACQUIRE_BUS(sc->sc_busdev, sc->sc_dev); > + GPIOBUS_PIN_SET(sc->sc_busdev, sc->sc_dev, 0, > + (val =3D=3D 0) ? GPIO_PIN_LOW : GPIO_PIN_HIGH); > + GPIOBUS_RELEASE_BUS(sc->sc_busdev, sc->sc_dev); > + GPIOBUS_UNLOCK_BUS(sc->sc_busdev); > + GPIO_SYSCTL_UNLOCK(sc); > +} > + > +static int > +gs_sysctl_handler(SYSCTL_HANDLER_ARGS) > +{ > + device_t dev; > + struct gpiosysctl_softc *sc; > + int val, ret; > + > + dev =3D (device_t)arg1; > + sc =3D device_get_softc(dev); > + if (req->newptr =3D=3D NULL) { > + val =3D gs_gpio_in(sc); > + ret =3D sysctl_handle_int(oidp, &val, 0, req); > + } else { > + ret =3D sysctl_handle_int(oidp, &val, 0, req); > + if (ret < 0 || ret > 1) { > + device_printf(dev, "%d: invalid value.\n", ret); > + ret =3D 0; > + } > + gs_gpio_out(sc, val); > + ret =3D val; > + } > + > + return (ret); > +} > + > +static int > +gs_attach(device_t dev) > +{ > + struct gpiosysctl_softc *sc; > + struct sysctl_ctx_list *ctx; > + struct sysctl_oid *oid; > + device_t pdev; > + const char *name; > + char nbuf[GPIOMAXNAME]; > + int flags; > + > + sc =3D device_get_softc(dev); > + sc->sc_dev =3D dev; > + sc->sc_busdev =3D device_get_parent(dev); > + GPIO_SYSCTL_LOCK_INIT(sc); > + > + if (resource_string_value(device_get_name(dev), = device_get_unit(dev), > + "name", &name) !=3D 0) { > + GPIOBUS_PIN_GETNAME(sc->sc_busdev, sc->sc_dev, 0, nbuf); > + nbuf[sizeof(nbuf) - 1] =3D '\0'; > + if (nbuf[0] !=3D '\0') > + name =3D nbuf; > + else { > + device_printf(dev, "no valid name.\n"); > + return (ENXIO); > + } > + } > + ctx =3D device_get_sysctl_ctx(dev); > + > + pdev =3D device_get_parent(dev); > + oid =3D device_get_sysctl_tree(pdev); > + flags =3D CTLTYPE_INT | CTLFLAG_RD; > + SYSCTL_ADD_PROC(ctx, SYSCTL_CHILDREN(oid), OID_AUTO, name, = flags, dev, > + 0, gs_sysctl_handler, "I", NULL); > + > + return (0); > +} > + > +static int > +gs_detach(device_t dev) > +{ > + struct gpiosysctl_softc *sc; > + > + sc =3D device_get_softc(dev); > + GPIO_SYSCTL_LOCK_DESTROY(sc); > + > + return (0); > +} > + > +static devclass_t gs_devclass; > + > +static device_method_t gs_methods[] =3D { > + /* Device interface */ > + DEVMETHOD(device_probe, gs_probe), > + DEVMETHOD(device_attach, gs_attach), > + DEVMETHOD(device_detach, gs_detach), > + { 0, 0 }, > +}; > + > +static driver_t gs_driver =3D { > + GPIO_SYSCTL_DEVNAME, > + gs_methods, > + sizeof(struct gpiosysctl_softc), > +}; > + > +DRIVER_MODULE(gpiosysctl, gpiobus, gs_driver, gs_devclass, 0, 0); > +MODULE_VERSION(gpiosysctl, 1); From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 16:25:08 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2A5441065672; Sun, 19 Aug 2012 16:25:08 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 13F1D8FC08; Sun, 19 Aug 2012 16:25:06 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7JG3CcY044828; Sun, 19 Aug 2012 16:03:12 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ij4p954sthnpfqmj9fqsfpcs5n; Sun, 19 Aug 2012 16:03:12 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> Date: Sun, 19 Aug 2012 09:03:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1278) Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 16:25:08 -0000 On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >=20 > In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. I noticed that Linux on BeagleBone does not simply number all pins as we do. Pins are identified by two numbers: a unit number and a pin number. The AM3358 SoC has a couple of GPIO modules, so this makes it pretty natural to map hardware diagrams (which refer to "pin 13 of GPIO module 1") to software.=20 I agree with Warner that masks are probably a bad idea at the framework level. But this all may have to wait for "gpioNG". Tim From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 17:02:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 457E6106564A for ; Sun, 19 Aug 2012 17:02:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0055E8FC15 for ; Sun, 19 Aug 2012 17:02:06 +0000 (UTC) Received: by obbun3 with SMTP id un3so11207030obb.13 for ; Sun, 19 Aug 2012 10:02:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qf61COc06Imk6lh8ZkUCHbcwu/gEQCuS3OxBge7lJ0E=; b=ovDPgOo/glv/oRVN+teYEV3pN3sfvYRu9kgOTrXjeusBFxJH3xdalZ6CZ6XQwTBEHr YKO6qC9df8m41YMEqmaVIf+eT5SQOBh+frigO+wz9/8ZLuKXIb4uVZjlFFImY+eVo3Xq AY2oAGlR4Cz6GySl4ikEOW9morbY+KdUdw6nB93b3CWWKq3LNNU7MhG3QghKR/gF1Gwt DGYlzKTbsktQPu+2dNWarUr3mydNPR1fB+fkL+MUbfCOlL5wUEg8FeArzjSV26F43hLF EsWpGHpTtyeurHyiLnT8u+cQSTHeRNrLPylthZNc39qqzLwLAurUWA9uY+kPa4sUXLEK OUZw== Received: by 10.50.6.168 with SMTP id c8mr7455076iga.21.1345395725065; Sun, 19 Aug 2012 10:02:05 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ul4sm10445391igb.15.2012.08.19.10.02.03 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 10:02:04 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 19 Aug 2012 11:02:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnAGv6Vziifi3ijwVNVPzOv2/Q0k8MX6lqshO7K4grqVoHiBy3HQ07JXNlK2vYq288Dursu Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 17:02:07 -0000 On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: > On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >=20 >>=20 >> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >=20 > I noticed that Linux on BeagleBone does not > simply number all pins as we do. Pins are identified by > two numbers: a unit number and a pin number. Is this in the code, or just in the FTD? On Atmel, there's a single = number from 0 to max-1 with all negative numbers being invalid. But = Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good = start, and 3.6 will add the missing pinmux/pinctl stuff). > The AM3358 SoC has a couple of GPIO modules, > so this makes it pretty natural to map hardware > diagrams (which refer to "pin 13 of GPIO module 1") to > software.=20 >=20 > I agree with Warner that masks are probably a bad > idea at the framework level. >=20 > But this all may have to wait for "gpioNG". As does all the pinctl/pinmux stuff... Linux is a fair bit ahead of us = in being able to configure individual pins, groups of pins, in/out = status, termination, etc. Pinctl/mux is the biggest part of the = board/SoC support code for Atmel at the moment, so one of my plans is to = transition those ports over as soon as the FTD stuff jells on the Linux = side. Plus Linux has more GPIOish things than we do. Support for buttons that = translate to a keyboard event, support for LEDs that's better than we = have, the ability to control pin drives, interrupt control for GPIOs, = etc. Makes for a lot less code and a richer experience. Warner From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 23:04:57 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F0EA106566C; Sun, 19 Aug 2012 23:04:57 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 64F708FC08; Sun, 19 Aug 2012 23:04:57 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7JN4tGV046266; Sun, 19 Aug 2012 23:04:55 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id k8j5ngyxbz43uag8ayyma6vwy2; Sun, 19 Aug 2012 23:04:54 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> Date: Sun, 19 Aug 2012 16:04:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1278) Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 23:04:57 -0000 On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >=20 > On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >=20 >> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>=20 >>>=20 >>> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >>=20 >> I noticed that Linux on BeagleBone does not >> simply number all pins as we do. Pins are identified by >> two numbers: a unit number and a pin number. >=20 > Is this in the code, or just in the FTD? On Atmel, there's a single = number from 0 to max-1 with all negative numbers being invalid. But = Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good = start, and 3.6 will add the missing pinmux/pinctl stuff). I'm not exactly sure what you mean. The Linux DTS file: = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts inherits most of the real functionality from = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi There are certainly separate entries there for each GPIO module. I = presume (but haven't verified) that the unit number maps directly to a = "gpio#" device name. Tim From owner-freebsd-arm@FreeBSD.ORG Sun Aug 19 23:42:06 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22287106566C for ; Sun, 19 Aug 2012 23:42:06 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id ACBC58FC14 for ; Sun, 19 Aug 2012 23:42:04 +0000 (UTC) Received: by ialo14 with SMTP id o14so2722426ial.13 for ; Sun, 19 Aug 2012 16:42:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Z7WBdGMxRPGKinxFjq6TPB4o2kPZ5fD/iboEWCdZXv0=; b=LYxH+qftkHNKRuy1bIN+9GuorUI3V0CcUKX4h/x4uuRmOxfks10y4xk6lpqJF7BRjO 1E0U49N9YXNxThkiGTFFFsD15kSC+oXYl/6TXuTYeuPE6Z8NxSAwK8tJVh0MpD5RDDjJ b7D9XjzJ63nnnV97OMPL/+ZQTOw3jtl2ABcVS1Zl4UJepJXg/IQdT2tkn9y3kGM/GZsd MLug3gCFmJgXr7+bBxrvBwCcckHa9YDXfQacBmuV+PQz8RpTW7C+ksa1CnGcOyEra2e/ pBGI6bBX8nQ15csDrFPb4PJPYFCGnfRoaIbNpg9Z1etPNOhb3tpIfh4uAmoWx5s53K+3 kpsA== Received: by 10.50.159.135 with SMTP id xc7mr8259160igb.1.1345419724138; Sun, 19 Aug 2012 16:42:04 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id i2sm7312747igl.8.2012.08.19.16.42.02 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 16:42:03 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> Date: Sun, 19 Aug 2012 17:42:01 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmg0OgwXg6swfb8kak9RdqcBJCQmfauO7LMIL/4Rno3jxYPhQi8vPg7uGvIqbqcfnSgyQ+s Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Aug 2012 23:42:06 -0000 On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: > On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >>=20 >> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >>=20 >>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>>=20 >>>>=20 >>>> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >>>=20 >>> I noticed that Linux on BeagleBone does not >>> simply number all pins as we do. Pins are identified by >>> two numbers: a unit number and a pin number. >>=20 >> Is this in the code, or just in the FTD? On Atmel, there's a single = number from 0 to max-1 with all negative numbers being invalid. But = Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good = start, and 3.6 will add the missing pinmux/pinctl stuff). >=20 > I'm not exactly sure what you mean. The Linux DTS file: >=20 > = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts >=20 > inherits most of the real functionality from >=20 > = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi >=20 > There are certainly separate entries there for each GPIO module. I = presume (but haven't verified) that the unit number maps directly to a = "gpio#" device name. There's similar things in the Atmel DTS files, but under the covers the = gpio pins map into a uniform space number 0 to 32*N-1, where N is the = number of GPIO units. Warner= From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 00:02:21 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7D8C1065679 for ; Mon, 20 Aug 2012 00:02:21 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 90FE88FC0C for ; Mon, 20 Aug 2012 00:02:21 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta03.emeryville.ca.mail.comcast.net with comcast id ojQX1j0020vp7WLA3o2FXu; Mon, 20 Aug 2012 00:02:15 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta05.emeryville.ca.mail.comcast.net with comcast id oo2E1j00S4NgCEG8Ro2FS3; Mon, 20 Aug 2012 00:02:15 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7K02Ccx020259; Sun, 19 Aug 2012 18:02:12 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Aug 2012 18:02:12 -0600 Message-ID: <1345420932.27688.298.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm@freebsd.org, gonzo@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 00:02:21 -0000 On Sun, 2012-08-19 at 17:42 -0600, Warner Losh wrote: > On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: > > > On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: > >> > >> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: > >> > >>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: > >>> > >>>> > >>>> In general, I like this code in the context of the current GPIO framework. I've been growing dissatisfied with the current GPIO framework, however, and some of my comments reflect that more than any comments about this specific code. > >>> > >>> I noticed that Linux on BeagleBone does not > >>> simply number all pins as we do. Pins are identified by > >>> two numbers: a unit number and a pin number. > >> > >> Is this in the code, or just in the FTD? On Atmel, there's a single number from 0 to max-1 with all negative numbers being invalid. But Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good start, and 3.6 will add the missing pinmux/pinctl stuff). > > > > I'm not exactly sure what you mean. The Linux DTS file: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am335x-bone.dts > > > > inherits most of the real functionality from > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/boot/dts/am33xx.dtsi > > > > There are certainly separate entries there for each GPIO module. I presume (but haven't verified) that the unit number maps directly to a "gpio#" device name. > > There's similar things in the Atmel DTS files, but under the covers the gpio pins map into a uniform space number 0 to 32*N-1, where N is the number of GPIO units. The possibility exists that there can be sets of gpios managed by different hardware that's completely unrelated. For example, you can have some number of gpio pins on an SoC, then have an iicbus device that provides a bunch more gpio pins. I'm not sure whether or not that confounds the idea of having a big zero-N address space for naming pins. Another annoying complexity is IRQs associated with pins. Some pins can directly generate IRQn on the SoC. Other pins are grouped together by device or bank or whatever, such that any change on pins M-N generates IRQn. Sharing the IRQ for the latter type between multiple drivers (each using one or more pins in the shared bank) can be tricky, because on some hardware, reading the status register that says which pins changed clears that register. I have no solutions to offer here, just throwing out a couple things I've run into in the past couple years. -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 00:45:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB91F106564A; Mon, 20 Aug 2012 00:45:31 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 863E38FC14; Mon, 20 Aug 2012 00:45:31 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7K0jSsH046634; Mon, 20 Aug 2012 00:45:28 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id zemfivjb2zbi45bkh4st5vmrds; Mon, 20 Aug 2012 00:45:28 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> Date: Sun, 19 Aug 2012 17:45:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1278) Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 00:45:31 -0000 On Aug 19, 2012, at 4:42 PM, Warner Losh wrote: >=20 > On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: >=20 >> On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >>>=20 >>> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >>>=20 >>>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>>>=20 >>>>>=20 >>>>> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >>>>=20 >>>> I noticed that Linux on BeagleBone does not >>>> simply number all pins as we do. Pins are identified by >>>> two numbers: a unit number and a pin number. >>>=20 >>> Is this in the code, or just in the FTD? On Atmel, there's a single = number from 0 to max-1 with all negative numbers being invalid. But = Atmel doesn't have proper FTD support in Linux just yet (3.5 has a good = start, and 3.6 will add the missing pinmux/pinctl stuff). >>=20 >> I'm not exactly sure what you mean. The Linux DTS file: >>=20 >> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts >>=20 >> inherits most of the real functionality from >>=20 >> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi >>=20 >> There are certainly separate entries there for each GPIO module. I = presume (but haven't verified) that the unit number maps directly to a = "gpio#" device name. >=20 > There's similar things in the Atmel DTS files, but under the covers = the gpio pins map into a uniform space number 0 to 32*N-1, where N is = the number of GPIO units. The "under the covers" part is exactly what bothers me about this. I've been reading documentation that says things like "LED#0 on the board is connected to GPIO#1 pin 13". I'd like to be able to take that to the command line and type in: $ gpio 1 13 on or $ gpio /dev/gpio1 13 on and see LED#0 turn on. Since GPIO is used by a lot of folks interfacing new hardware, this kind of translation between hardware interface and software API needs to be trivial. How would the linear addressing approach handle, for example, hot-plugging of a device that provided a USB interface to a group of GPIO pins? (That is, it plugs into the USB port on the board and provides a GPIO header on the other end. Not vice versa. ;-) Tim From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 02:07:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCFD51065672 for ; Mon, 20 Aug 2012 02:07:36 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 69B8D8FC15 for ; Mon, 20 Aug 2012 02:07:36 +0000 (UTC) Received: by yenl7 with SMTP id l7so5866857yen.13 for ; Sun, 19 Aug 2012 19:07:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=4zX/Eor9R4TxZzysoGYI0jawIe9/Q3VnIef8DsUaVuo=; b=TE9uFnH7dxh+ckySjRE5nxzpXwDyq6WPvtkGETIALjk8w+GoqkS0HtTCTSNsAA8qfo Km6bdWOi+toZyZ/KIVYJ8ACHDXTvP06xWiAugaNTNLt+BWgZ8uIPQWfjD+g1xBKHiPoe VMEIRoJ6KCsagPShbhdIdOVm31gl+SeYiboxFkH4MTwa1eHwzysvAxQHTMkzY2V7peGX xuzPf6YxjdrLcYstXHIjJg0KV2T7QD2TU3+Qv6EWB4Big6C5/OLMsl6hknLhTf+HU9Ua ZIDJbAdl9fkAg7SNxye8u7AXPv/ZbDEZ8Ewlh0zkK2NNFCiqK/BAFVYQnkmturlX5C7K at3Q== Received: by 10.50.182.162 with SMTP id ef2mr8300699igc.43.1345428449591; Sun, 19 Aug 2012 19:07:29 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ud8sm23075730igb.4.2012.08.19.19.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 19:07:28 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345420932.27688.298.camel@revolution.hippie.lan> Date: Sun, 19 Aug 2012 20:07:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> <1345420932.27688.298.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkTLbV7W3lm9C7lzL6MRw4aq1Q5G9SyaGkEafUd1F1SARLkmtwM+pNb2O9D9DWu2CtttoRK Cc: Tim Kientzle , freebsd-arm@freebsd.org, gonzo@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 02:07:36 -0000 On Aug 19, 2012, at 6:02 PM, Ian Lepore wrote: > On Sun, 2012-08-19 at 17:42 -0600, Warner Losh wrote: >> On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: >>=20 >>> On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >>>>=20 >>>> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >>>>=20 >>>>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>>>>=20 >>>>>>=20 >>>>>> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >>>>>=20 >>>>> I noticed that Linux on BeagleBone does not >>>>> simply number all pins as we do. Pins are identified by >>>>> two numbers: a unit number and a pin number. >>>>=20 >>>> Is this in the code, or just in the FTD? On Atmel, there's a = single number from 0 to max-1 with all negative numbers being invalid. = But Atmel doesn't have proper FTD support in Linux just yet (3.5 has a = good start, and 3.6 will add the missing pinmux/pinctl stuff). >>>=20 >>> I'm not exactly sure what you mean. The Linux DTS file: >>>=20 >>> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts >>>=20 >>> inherits most of the real functionality from >>>=20 >>> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi >>>=20 >>> There are certainly separate entries there for each GPIO module. I = presume (but haven't verified) that the unit number maps directly to a = "gpio#" device name. >>=20 >> There's similar things in the Atmel DTS files, but under the covers = the gpio pins map into a uniform space number 0 to 32*N-1, where N is = the number of GPIO units. >=20 > The possibility exists that there can be sets of gpios managed by > different hardware that's completely unrelated. For example, you can > have some number of gpio pins on an SoC, then have an iicbus device = that > provides a bunch more gpio pins. I'm not sure whether or not that > confounds the idea of having a big zero-N address space for naming = pins. Not really. Like interrupts, they can come from many different sources. = Yet, IRQs are well ordered. Each platform defines how they are = numbered differently, and I wasn't suggesting that the Atmel mapping = would be universal. The mapping is just a by the way this is one way it = is done, not this is the only, or best, way to do it everywhere. > Another annoying complexity is IRQs associated with pins. Some pins = can > directly generate IRQn on the SoC. Other pins are grouped together by > device or bank or whatever, such that any change on pins M-N generates > IRQn. Sharing the IRQ for the latter type between multiple drivers > (each using one or more pins in the shared bank) can be tricky, = because > on some hardware, reading the status register that says which pins > changed clears that register. It is no trickier than sharing it back in the at-pic days. > I have no solutions to offer here, just throwing out a couple things > I've run into in the past couple years. Understood.= From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 02:14:59 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FE9C106564A for ; Mon, 20 Aug 2012 02:14:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 389818FC12 for ; Mon, 20 Aug 2012 02:14:59 +0000 (UTC) Received: by obbun3 with SMTP id un3so11973463obb.13 for ; Sun, 19 Aug 2012 19:14:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sJOCFsAv9vJrEix6MiVdLMt4mSq2vBfjDXY4qsaEa6A=; b=PeIVuewpr4ObY6w6/7mlbxjX5d45LeqlK2EX4mDoFlYlpip8MMF9zkXp8TSQpb9rL3 LtCqEuVHlHiPhxlhjZvKZyIF3n0eSQNDRAGO41PU8RhBaFGPZCr4fKOXqv4h9KVljOn3 hEtmaaaORnV3g0O3nmM7Cu9BFoxjjATd+ZIX2PMmSmSwY7HkwBYVivr+aLZlR3UxjgS7 3tmVJ76MMpkP0JmJOwdHWgXTL75f8pe8skABxLVdrCvbiazvh5d0zOxRzODGL7L7eq2U UqOZeUUFld7c9uJPD2Gilz4QDFGXrj67gIvKgNQ+lDhYegqRcOXw6H4z9hkH2Zx84Zkl pdNQ== Received: by 10.50.46.170 with SMTP id w10mr8244498igm.44.1345428898109; Sun, 19 Aug 2012 19:14:58 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id wm7sm23098725igb.6.2012.08.19.19.14.56 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Aug 2012 19:14:57 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.com> Date: Sun, 19 Aug 2012 20:14:55 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <284D7D21-D87B-4112-BBDB-17CA0F9A6FDD@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> <7E6C76BE-1D3F-40E4-BFE3-DC88715C234C@bsdimp.com> <12A967D8-BC49-49AF-BBD9-40E259932617@kientzle.com> <974EEF9B-08C2-4876-9223-48DD4ABDFC99@bsdimp.com> <1501020F-38C8-44E9-82B3-64DF1090A983@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkIxdhkum349ZLKm6cj/F5mu9TM2UzhvldzY5Px0cI1Pn9xqyW/9L7KLfDpuSVUEViAPlEL Cc: gonzo@freebsd.org, freebsd-arm@freebsd.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 02:14:59 -0000 On Aug 19, 2012, at 6:45 PM, Tim Kientzle wrote: >=20 > On Aug 19, 2012, at 4:42 PM, Warner Losh wrote: >=20 >>=20 >> On Aug 19, 2012, at 5:04 PM, Tim Kientzle wrote: >>=20 >>> On Aug 19, 2012, at 10:02 AM, Warner Losh wrote: >>>>=20 >>>> On Aug 19, 2012, at 10:03 AM, Tim Kientzle wrote: >>>>=20 >>>>> On Aug 19, 2012, at 8:38 AM, Warner Losh wrote: >>>>>=20 >>>>>>=20 >>>>>> In general, I like this code in the context of the current GPIO = framework. I've been growing dissatisfied with the current GPIO = framework, however, and some of my comments reflect that more than any = comments about this specific code. >>>>>=20 >>>>> I noticed that Linux on BeagleBone does not >>>>> simply number all pins as we do. Pins are identified by >>>>> two numbers: a unit number and a pin number. >>>>=20 >>>> Is this in the code, or just in the FTD? On Atmel, there's a = single number from 0 to max-1 with all negative numbers being invalid. = But Atmel doesn't have proper FTD support in Linux just yet (3.5 has a = good start, and 3.6 will add the missing pinmux/pinctl stuff). >>>=20 >>> I'm not exactly sure what you mean. The Linux DTS file: >>>=20 >>> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am335x-bone.dts >>>=20 >>> inherits most of the real functionality from >>>=20 >>> = http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux.git;a=3Dblob;f=3D= arch/arm/boot/dts/am33xx.dtsi >>>=20 >>> There are certainly separate entries there for each GPIO module. I = presume (but haven't verified) that the unit number maps directly to a = "gpio#" device name. >>=20 >> There's similar things in the Atmel DTS files, but under the covers = the gpio pins map into a uniform space number 0 to 32*N-1, where N is = the number of GPIO units. >=20 > The "under the covers" part is exactly what bothers me > about this. This makes a number of interfaces a simple int, rather than having some = kind of struct. > I've been reading documentation that says things like > "LED#0 on the board is connected to GPIO#1 pin 13". I'd > like to be able to take that to the command line and type in: > $ gpio 1 13 on > or > $ gpio /dev/gpio1 13 on > and see LED#0 turn on. Yet other documentation says "The LED is connected to PC23" which has no = simple mapping to this stuff. Sure that's gpio2, since that's what = would most likely get PIOC from the chip, but it could just as easily be = 3 since C is the 3rd letter of the alphabet. > Since GPIO is used by a lot of folks interfacing new > hardware, this kind of translation between hardware > interface and software API needs to be trivial. Correct. The current mapping we have is insane. We have to have a = base-address of the GPIO hardware, coupled with a mask and pass that = complex thing around, when we could more easily pass around a simple = int. Linux did it this way to make their board files easier to cope = with. I'm not sure how it is exposed outside the kernel, honestly. = Given the trend to FDT, tuples aren't too bad to carry around since you = don't have to contrive them to be in free code as much. > How would the linear addressing approach > handle, for example, hot-plugging of a device that > provided a USB interface to a group of GPIO pins? > (That is, it plugs into the USB port on the board > and provides a GPIO header on the other end. > Not vice versa. ;-) Each platform would have a fixed set of pins, followed by a dynamically = allocated range for the odd-ball situations like this. For most things, gpio does single bit, and for single bit on one of many = GPIOs units, masks are a pain. But until I have gpioNG going, along with the pinctl and pinmux support = with DTS tie ins, I guess I'm just flapping my yapper, eh? Warner From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 02:53:21 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 70329106564A; Mon, 20 Aug 2012 02:53:21 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 984728FC0A; Mon, 20 Aug 2012 02:53:19 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q7K2qxlP067111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 11:53:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q7K2qvvM058883; Mon, 20 Aug 2012 11:52:59 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 20 Aug 2012 11:51:02 +0900 (JST) Message-Id: <20120820.115102.2041268449045028507.hrs@allbsd.org> To: imp@bsdimp.com From: Hiroki Sato In-Reply-To: <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> References: <20120819.171723.523519054460575158.hrs@allbsd.org> <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Mon_Aug_20_11_51_02_2012_300)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 20 Aug 2012 11:53:10 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,QENCPTR1,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: gonzo@FreeBSD.org, freebsd-arm@FreeBSD.org Subject: Re: gpiobus_hinted_child >32 pins support, pin_getname method, and gpio-sysctl bridge patch X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 02:53:21 -0000 ----Security_Multipart0(Mon_Aug_20_11_51_02_2012_300)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_20_11_51_02_2012_584)--" Content-Transfer-Encoding: 7bit ----Next_Part(Mon_Aug_20_11_51_02_2012_584)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Warner Losh wrote in <8CDAB51C-14A0-42F0-8E16-43A3EABA2703@bsdimp.com>: im> im> On Aug 19, 2012, at 2:17 AM, Hiroki Sato wrote: im> im> > Hi, im> im> Hi Sato-san, im> im> In general, I like this code in the context of the current GPIO im> framework. I've been growing dissatisfied with the current GPIO im> framework, however, and some of my comments reflect that more than any im> comments about this specific code. im> im> > Can you review the attached patches? The first one is to add >32 pins im> > support for hint.devname.%d.pins and pin_getname method into gpiobus im> > similar to gpio interface. After applying this, the following hint im> > will be supported: im> > im> > hint.gpioled.0.at="gpiobus0" im> > hint.gpioled.0.pins0="0x00000000" # 41 im> > hint.gpioled.0.pins1="0x00000200" im> im> This is, at best, awkward. Why not '41' here? im> im> Why not hints.gpioled.0.pins0=41? Ah, the reason why I used the mask was to simply reuse the old interface. The attached patch supports the following: hint.gpioled.0.at="gpiobus0" hint.gpioled.0.pins.0="10" hint.gpioled.0.pins.1="41" hint.gpioled.0.pins.2="43" My primary frustration was it was limited to 32 pins, so I am wondering if someone has a strong objection or not ;) im> In general, the gpio stuff is too mask heavy and should be more pin im> oriented. We also need a more generic way to pass around all the GPIO im> pins used for aux functions of embedded devices. which pin is used im> for media status interrupts, write protect detection, vcc power, etc. im> im> Looks a lot like we already keep book internally in pins. im> I was rather hoping to recast much of the GPIO stuff so we can also im> support interrupts based on pin numbers for any device in the tree. im> I'd like this for a gpiokey generic interface that devices can im> register button presses. How does one configure in vs out for these im> pins? And how does one guard against trying to use the GPIO pins for im> things like ethernet? Again, that may be beyond the scope of what you im> are trying to achieve. Agreed. I was exploring more generic way to configure GPIO connection via DTS, hints, and/or gpiobus for some time, but it was difficult to do such things without device-specific code. Although in/out initialization for each pin can be done via DTS (when the gpio driver attached and read gpios property), there seems no way to configure pin-to-interrupt relationship in the bindings. I am not familiar with DTS syntax but the interrupt-map property can be utilized to specify it. -- Hiroki ----Next_Part(Mon_Aug_20_11_51_02_2012_584)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="gpiobus-part-20120820-1.diff" Index: sys/dev/gpio/gpiobus.c =================================================================== --- sys/dev/gpio/gpiobus.c (revision 239381) +++ sys/dev/gpio/gpiobus.c (working copy) @@ -40,6 +40,7 @@ #include #include #include +#include #include #include @@ -47,7 +48,9 @@ #include "gpiobus_if.h" static void gpiobus_print_pins(struct gpiobus_ivar *); -static int gpiobus_parse_pins(struct gpiobus_softc *, device_t, int); +static int gpiobus_register_pins(struct gpiobus_softc *, device_t, int *, + size_t); +static int gpiobus_parse_pinmask(int, int *, size_t); static int gpiobus_probe(device_t); static int gpiobus_attach(device_t); static int gpiobus_detach(device_t); @@ -69,6 +72,7 @@ static int gpiobus_pin_setflags(device_t, device_t, uint32_t, uint32_t); static int gpiobus_pin_getflags(device_t, device_t, uint32_t, uint32_t*); static int gpiobus_pin_getcaps(device_t, device_t, uint32_t, uint32_t*); +static int gpiobus_pin_getname(device_t, device_t, uint32_t, char *); static int gpiobus_pin_set(device_t, device_t, uint32_t, unsigned int); static int gpiobus_pin_get(device_t, device_t, uint32_t, unsigned int*); static int gpiobus_pin_toggle(device_t, device_t, uint32_t); @@ -82,6 +86,8 @@ #define GPIOBUS_ASSERT_LOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_OWNED); #define GPIOBUS_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED); +#define GPIOBUS_PINS_MAX 128 +static char pinsmib[] = "pins.NNN"; static void gpiobus_print_pins(struct gpiobus_ivar *devi) @@ -119,17 +125,12 @@ } static int -gpiobus_parse_pins(struct gpiobus_softc *sc, device_t child, int mask) +gpiobus_register_pins(struct gpiobus_softc *sc, device_t child, int *pin, + size_t npins) { struct gpiobus_ivar *devi = GPIOBUS_IVAR(child); - int i, npins; + int i; - npins = 0; - for (i = 0; i < 32; i++) { - if (mask & (1 << i)) - npins++; - } - if (npins == 0) { device_printf(child, "empty pin mask"); return (EINVAL); @@ -142,34 +143,37 @@ if (!devi->pins) return (ENOMEM); - npins = 0; - for (i = 0; i < 32; i++) { - - if ((mask & (1 << i)) == 0) - continue; - - if (i >= sc->sc_npins) { - device_printf(child, - "invalid pin %d, max: %d\n", i, sc->sc_npins - 1); - return (EINVAL); - } - - devi->pins[npins++] = i; + for (i = 0; i < npins; i++) { + devi->pins[i] = pin[i]; /* * Mark pin as mapped and give warning if it's already mapped */ - if (sc->sc_pins_mapped[i]) { + if (sc->sc_pins_mapped[pin[i]]) { device_printf(child, - "warning: pin %d is already mapped\n", i); + "warning: pin %d is already mapped\n", pin[i]); return (EINVAL); } - sc->sc_pins_mapped[i] = 1; } return (0); } static int +gpiobus_parse_pinmask(int mask, int *pins, size_t pinmax) +{ + int i, npins; + + npins = 0; + for (i = 0; i < sizeof(mask) * 8 && i < pinmax; i++) { + if (mask & (1 << i)) { + pins[npins++] = i; + } + } + + return (npins); +} + +static int gpiobus_probe(device_t dev) { device_set_desc(dev, "GPIO bus"); @@ -192,6 +196,8 @@ * Increase to get number of pins */ sc->sc_npins++; + if (bootverbose) + device_printf(dev, "number of pins = %d\n", sc->sc_npins); KASSERT(sc->sc_npins != 0, ("GPIO device with no pins")); @@ -310,13 +316,40 @@ struct gpiobus_softc *sc = GPIOBUS_SOFTC(bus); struct gpiobus_ivar *devi; device_t child; - int pins; + int i, error, mask, pins[GPIOBUS_PINS_MAX]; + bzero((char *)&pins, sizeof(pins)); child = BUS_ADD_CHILD(bus, 0, dname, dunit); devi = GPIOBUS_IVAR(child); - resource_int_value(dname, dunit, "pins", &pins); - if (gpiobus_parse_pins(sc, child, pins)) + if (resource_int_value(dname, dunit, "pins", &mask) == 0) { + /* + * Backward compatibility for 32-pinmask configuration in a + * 32-bit hint: + * + * hint.devname.%d.pins=0x00000000 + */ + i = gpiobus_parse_pinmask(mask, pins, + sizeof(pins)/sizeof(pins[0])); + error = gpiobus_register_pins(sc, child, pins, i); + } else { + /* + * GPIO pin spec in the following MIB: + * + * hint.devname.%d.pins.0="41" + * hint.devname.%d.pins.1="42" + * hint.devname.%d.pins.2="44" + */ + for (i = 0; i < sizeof(pins)/sizeof(pins[0]); i++) { + snprintf(pinsmib, sizeof(pinsmib), "pins.%d", i); + error = resource_int_value(dname, dunit, pinsmib, + &pins[i]); + if (error) + break; + } + error = gpiobus_register_pins(sc, child, pins, i); + } + if (error) device_delete_child(bus, child); } @@ -409,6 +442,18 @@ } static int +gpiobus_pin_getname(device_t dev, device_t child, uint32_t pin, char *name) +{ + struct gpiobus_softc *sc = GPIOBUS_SOFTC(dev); + struct gpiobus_ivar *devi = GPIOBUS_IVAR(child); + + if (pin >= devi->npins) + return (EINVAL); + + return GPIO_PIN_GETNAME(sc->sc_dev, devi->pins[pin], name); +} + +static int gpiobus_pin_set(device_t dev, device_t child, uint32_t pin, unsigned int value) { @@ -469,6 +514,7 @@ DEVMETHOD(gpiobus_release_bus, gpiobus_release_bus), DEVMETHOD(gpiobus_pin_getflags, gpiobus_pin_getflags), DEVMETHOD(gpiobus_pin_getcaps, gpiobus_pin_getcaps), + DEVMETHOD(gpiobus_pin_getname, gpiobus_pin_getname), DEVMETHOD(gpiobus_pin_setflags, gpiobus_pin_setflags), DEVMETHOD(gpiobus_pin_get, gpiobus_pin_get), DEVMETHOD(gpiobus_pin_set, gpiobus_pin_set), ----Next_Part(Mon_Aug_20_11_51_02_2012_584)---- ----Security_Multipart0(Mon_Aug_20_11_51_02_2012_300)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlAxphYACgkQTyzT2CeTzy3DUwCgt47Z67bDOkxjtP9ii4Y8o3FD 28YAn0prC1RTEaCrTrHgGELjr4m5g2IH =0sjj -----END PGP SIGNATURE----- ----Security_Multipart0(Mon_Aug_20_11_51_02_2012_300)---- From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 03:24:33 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70B211065670; Mon, 20 Aug 2012 03:24:33 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1846F8FC08; Mon, 20 Aug 2012 03:24:32 +0000 (UTC) Received: from [199.165.180.40] (dhcp10.beta.com [199.165.180.40]) by spoon.beta.com (8.14.5/8.14.5) with ESMTP id q7K2waaT025599; Sun, 19 Aug 2012 22:58:36 -0400 (EDT) (envelope-from mcgovern@beta.com) From: "Brian J. McGovern" To: freebsd-arm@freebsd.org, hrs@freebsd.org In-Reply-To: <20120803120026.2196B106568F@hub.freebsd.org> References: <20120803120026.2196B106568F@hub.freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 19 Aug 2012 22:58:36 -0400 Message-ID: <1345431516.1608.6.camel@fbsd-workstation.beta.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.0 required=5.0 tests=T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on spoon.beta.com Cc: Subject: Re: freebsd-arm Digest, Vol 329, Issue 5 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 03:24:33 -0000 On Fri, 2012-08-03 at 12:00 +0000, freebsd-arm-request@freebsd.org wrote: > Date: Fri, 3 Aug 2012 05:58:53 GMT > From: hrs@FreeBSD.org > Subject: Re: arm/156814: OpenRD Ultimate does not boot on DB-88F6XXX > or SHEEVAPLUG kernel configurations > To: hrs@FreeBSD.org, freebsd-arm@FreeBSD.org, hrs@FreeBSD.org > Message-ID: <201208030558.q735wrqE082699@freefall.freebsd.org> > > Synopsis: OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAPLUG > kernel configurations > > Responsible-Changed-From-To: freebsd-arm->hrs > Responsible-Changed-By: hrs > Responsible-Changed-When: Fri Aug 3 05:58:30 UTC 2012 > Responsible-Changed-Why: > I'll take this. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156814 > > I have a patch set working based on FreeBSD 9.0 for the OpenRD Ultimate derived from the patch set in the bug (with additional contributions and changes). It boots the kernel from NAND, and I have a mostly working driver for the SD card. There appears to be an initialization problem in the code - presently, I have about a half dozen lines #ifdef'ed so that it will work with an already installed SD (it will panic if its removed and reinserted), or it will work if you insert the SD card after boot (you can insert and remove to your heart's content, but if you boot the box with an SD card installed, it will panic). Late last week, I had started the process of building some diffs from my code base to move it forward to 9.1 or -current. If this would be helpful to you in any way, let me know. Similarly, if you need any testing... -Brian From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 03:54:09 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31059106566B for ; Mon, 20 Aug 2012 03:54:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 349DB8FC08 for ; Mon, 20 Aug 2012 03:54:08 +0000 (UTC) Received: from alph.allbsd.org (p2214-ipbf2707funabasi.chiba.ocn.ne.jp [123.225.119.214]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id q7K3rlUW079416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Aug 2012 12:53:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id q7K3rkTO059485; Mon, 20 Aug 2012 12:53:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 20 Aug 2012 12:51:38 +0900 (JST) Message-Id: <20120820.125138.1414176178021779806.hrs@allbsd.org> To: mcgovern@beta.com From: Hiroki Sato In-Reply-To: <1345431516.1608.6.camel@fbsd-workstation.beta.com> References: <20120803120026.2196B106568F@hub.freebsd.org> <1345431516.1608.6.camel@fbsd-workstation.beta.com> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Aug_20_12_51_38_2012_302)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 20 Aug 2012 12:53:58 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,QENCPTR1,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-arm@FreeBSD.org Subject: Re: freebsd-arm Digest, Vol 329, Issue 5 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 03:54:09 -0000 ----Security_Multipart(Mon_Aug_20_12_51_38_2012_302)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Brian J. McGovern" wrote in <1345431516.1608.6.camel@fbsd-workstation.beta.com>: mc> On Fri, 2012-08-03 at 12:00 +0000, freebsd-arm-request@freebsd.org mc> wrote: mc> > Date: Fri, 3 Aug 2012 05:58:53 GMT mc> > From: hrs@FreeBSD.org mc> > Subject: Re: arm/156814: OpenRD Ultimate does not boot on DB-88F6XXX mc> > or SHEEVAPLUG kernel configurations mc> > To: hrs@FreeBSD.org, freebsd-arm@FreeBSD.org, hrs@FreeBSD.org mc> > Message-ID: <201208030558.q735wrqE082699@freefall.freebsd.org> mc> > mc> > Synopsis: OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAPLUG mc> > kernel configurations mc> > mc> > Responsible-Changed-From-To: freebsd-arm->hrs mc> > Responsible-Changed-By: hrs mc> > Responsible-Changed-When: Fri Aug 3 05:58:30 UTC 2012 mc> > Responsible-Changed-Why: mc> > I'll take this. mc> > mc> > http://www.freebsd.org/cgi/query-pr.cgi?pr=156814 mc> > mc> > mc> mc> I have a patch set working based on FreeBSD 9.0 for the OpenRD Ultimate mc> derived from the patch set in the bug (with additional contributions and mc> changes). It boots the kernel from NAND, and I have a mostly working mc> driver for the SD card. There appears to be an initialization problem in mc> the code - presently, I have about a half dozen lines #ifdef'ed so that mc> it will work with an already installed SD (it will panic if its removed mc> and reinserted), or it will work if you insert the SD card after boot mc> (you can insert and remove to your heart's content, but if you boot the mc> box with an SD card installed, it will panic). mc> mc> Late last week, I had started the process of building some diffs from my mc> code base to move it forward to 9.1 or -current. mc> mc> If this would be helpful to you in any way, let me know. Similarly, if mc> you need any testing... If you have a revised patch set please send it to me. I am working on multiple Kirkwood-based boards including OpenRD now and will commit the necessary changes. -- Hiroki ----Security_Multipart(Mon_Aug_20_12_51_38_2012_302)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlAxtEoACgkQTyzT2CeTzy0mMwCgv2DGb0R01UcU6dILNNrVbLAw G0MAnjh3uFdkh5+eomFBNFIZ51mtNPWX =7mRf -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Aug_20_12_51_38_2012_302)---- From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 04:56:56 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F0F4C106566B for ; Mon, 20 Aug 2012 04:56:55 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id C473C8FC14 for ; Mon, 20 Aug 2012 04:56:55 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q7K4usr0047776 for freebsd-arm@freebsd.org; Mon, 20 Aug 2012 04:56:54 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id gfuztxy72zncerrcury7dwwtgn; for freebsd-arm@freebsd.org; Mon, 20 Aug 2012 04:56:54 +0000 (UTC) (envelope-from kientzle@freebsd.org) From: Tim Kientzle Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Aug 2012 21:56:53 -0700 Message-Id: <2685426E-3B97-40AA-B3BE-3CD4382EB5C8@freebsd.org> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: BeagleBone crash at boot... X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 04:56:56 -0000 Updating my system build scripts to use FreeBSD-CURRENT since Oleksander merged the old armv6 tree. I'm using unmodified sources from SVN r239395 and it crashes at boot. Here's the last part of the boot messages: am335x_prcm0: mem = 0xe4e00000-0xe4e012ff on simplebus0 am335x_prcm0: Clocks: System 24.0 MHz, CPU 500 MHz am335x_dmtimer0: mem = 0xe4e05000-0xe4e05fff,0xe4e31000-0xe4e31fff,0xca611000-0xca611fff,0xca6120= 00-0xca612fff,0xca613000-0xca613fff,0xca614000-0xca614fff,0xca615000-0xca6= 15fff,0xca616000-0xca616fff irq 66,67,68,69,92,93,94,95 on simplebus0 Timecounter "AM335x Timecouter" frequency 24000000 Hz quality 1000 Event timer "AM335x Eventtimer0" frequency 24000000 Hz quality 1000 gpio0: mem = 0xe4e07000-0xe4e07fff,0xca617000-0xca617fff,0xca618000-0xca618fff,0xca6190= 00-0xca619fff irq 17,19,21,23 on simplebus0 gpioc0: on gpio0 gpiobus0: on gpio0 uart0: <16750 or compatible> mem 0xe4e09000-0xe4e09fff irq 72 on = simplebus0 uart0: console (115384,n,8,1) ti_mmchs0: mem = 0xcaa1a000-0xcaa1afff irq 64 on simplebus0 vm_fault(0xc0579480, 0, 1, 0) -> 1 Fatal kernel mode data abort: 'Translation Fault (S)' trapframe: 0xc06fcb78 FSR=3D00000005, FAR=3D00000004, spsr=3D60000093 r0 =3D00000000, r1 =3De4e00000, r2 =3D00000024, r3 =3D00000000 r4 =3Dc06ecf54, r5 =3Dc1c10100, r6 =3Dc1c0e200, r7 =3Dc1c0e200 r8 =3D00000001, r9 =3Dc1c0e240, r10=3D00000000, r11=3Dc06fcbe8 r12=3Dc0571b4c, ssp=3Dc06fcbc4, slr=3Dc049f9e8, pc =3Dc04a0a34 [ thread pid 0 tid 100000 ] Stopped at ti_edma3_init+0x24: ldr r3, [r3, #0x004] db> I believe this is the relevant portion of the backtrace: data_abort_handler() at data_abort_handler+0xc scp=3D0xc0499cf8 rlv=3D0xc048d684 (address_exception_entry+0x50) rsp=3D0xc06fcb78 rfp=3D0xc06fcbe8 r10=3D0x00000000 r9=3D0xc1c0e240 r8=3D0x00000001 r7=3D0xc1c0e200 r6=3D0xc1c0e200 r5=3D0xc1c10100 r4=3D0xc06ecf54 ti_edma3_init() at ti_edma3_init+0xc scp=3D0xc04a0a1c rlv=3D0xc04a17ac (ti_edma3_init+0xd9c) rsp=3D0xc06fcbec rfp=3D0xc06fcc44 r10=3D0xffffffff r8=3D0x00000001 r7=3D0xc1c0e200 r6=3D0xc1c0e200 r5=3D0xc1c10100 r4=3D0x00000000 ti_edma3_init() at ti_edma3_init+0xacc scp=3D0xc04a14dc rlv=3D0xc0324f94 (device_attach+0x2d8) rsp=3D0xc06fcc48 rfp=3D0xc06fcc84 r10=3D0xc1c10100 r9=3D0xc1bb6780 r8=3D0xffffffff r7=3D0xc0322b10 r6=3D0xc1c10150 r5=3D0x80000003 r4=3D0xc1bb6780 device_attach() at device_attach+0xc scp=3D0xc0324cc8 rlv=3D0xc0325c64 (device_probe_and_attach+0x48) rsp=3D0xc06fcc88 rfp=3D0xc06fcc98 r10=3D0xc1bb6780 r8=3D0xc1bdae80 r7=3D0xc1bdae94 r6=3D0xc1bb6780 r5=3D0xc1bdae80 r4=3D0xc1c10100 device_probe_and_attach() at device_probe_and_attach+0xc scp=3D0xc0325c28 rlv=3D0xc0325c94 (bus_generic_attach+0x20) rsp=3D0xc06fcc9c rfp=3D0xc06fccac r4=3D0xc1c10100 bus_generic_attach() at bus_generic_attach+0xc scp=3D0xc0325c80 rlv=3D0xc0231994 (fdt_immr_addr+0x1008) rsp=3D0xc06fccb0 rfp=3D0xc06fccd0 r4=3D0x00000000 I'll dig into this more later this week. Tim From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 11:07:37 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBC2A106564A for ; Mon, 20 Aug 2012 11:07:37 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D63848FC0A for ; Mon, 20 Aug 2012 11:07:37 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q7KB7bos047075 for ; Mon, 20 Aug 2012 11:07:37 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q7KB7aIB047007 for freebsd-arm@FreeBSD.org; Mon, 20 Aug 2012 11:07:36 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Aug 2012 11:07:36 GMT Message-Id: <201208201107.q7KB7aIB047007@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 11:07:38 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 13 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 12:12:33 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 53297106567C; Mon, 20 Aug 2012 12:12:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C822B8FC20; Mon, 20 Aug 2012 12:12:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q7KCCW99093396; Mon, 20 Aug 2012 08:12:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q7KCCW2M093395; Mon, 20 Aug 2012 12:12:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 20 Aug 2012 12:12:32 GMT Message-Id: <201208201212.q7KCCW2M093395@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 12:12:33 -0000 TB --- 2012-08-20 10:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-08-20 10:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-20 10:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-08-20 10:40:00 - cleaning the object tree TB --- 2012-08-20 10:40:00 - cvsupping the source tree TB --- 2012-08-20 10:40:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-08-20 10:41:06 - building world TB --- 2012-08-20 10:41:06 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 10:41:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 10:41:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 10:41:06 - SRCCONF=/dev/null TB --- 2012-08-20 10:41:06 - TARGET=arm TB --- 2012-08-20 10:41:06 - TARGET_ARCH=arm TB --- 2012-08-20 10:41:06 - TZ=UTC TB --- 2012-08-20 10:41:06 - __MAKE_CONF=/dev/null TB --- 2012-08-20 10:41:06 - cd /src TB --- 2012-08-20 10:41:06 - /usr/bin/make -B buildworld >>> World build started on Mon Aug 20 10:41:07 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Aug 20 11:43:37 UTC 2012 TB --- 2012-08-20 11:43:37 - cd /src/sys/arm/conf TB --- 2012-08-20 11:43:37 - /usr/sbin/config -m ARMADAXP TB --- 2012-08-20 11:43:37 - skipping ARMADAXP kernel TB --- 2012-08-20 11:43:37 - cd /src/sys/arm/conf TB --- 2012-08-20 11:43:37 - /usr/sbin/config -m ATMEL TB --- 2012-08-20 11:43:37 - building ATMEL kernel TB --- 2012-08-20 11:43:37 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:43:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:43:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:43:37 - SRCCONF=/dev/null TB --- 2012-08-20 11:43:37 - TARGET=arm TB --- 2012-08-20 11:43:37 - TARGET_ARCH=arm TB --- 2012-08-20 11:43:37 - TZ=UTC TB --- 2012-08-20 11:43:37 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:43:37 - cd /src TB --- 2012-08-20 11:43:37 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Mon Aug 20 11:43:37 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Mon Aug 20 11:47:11 UTC 2012 TB --- 2012-08-20 11:47:11 - cd /src/sys/arm/conf TB --- 2012-08-20 11:47:11 - /usr/sbin/config -m AVILA TB --- 2012-08-20 11:47:11 - skipping AVILA kernel TB --- 2012-08-20 11:47:11 - cd /src/sys/arm/conf TB --- 2012-08-20 11:47:11 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-08-20 11:47:11 - skipping BEAGLEBONE kernel TB --- 2012-08-20 11:47:11 - cd /src/sys/arm/conf TB --- 2012-08-20 11:47:11 - /usr/sbin/config -m BWCT TB --- 2012-08-20 11:47:11 - building BWCT kernel TB --- 2012-08-20 11:47:11 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:47:11 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:47:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:47:11 - SRCCONF=/dev/null TB --- 2012-08-20 11:47:11 - TARGET=arm TB --- 2012-08-20 11:47:11 - TARGET_ARCH=arm TB --- 2012-08-20 11:47:11 - TZ=UTC TB --- 2012-08-20 11:47:11 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:47:11 - cd /src TB --- 2012-08-20 11:47:11 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Aug 20 11:47:11 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Aug 20 11:49:21 UTC 2012 TB --- 2012-08-20 11:49:21 - cd /src/sys/arm/conf TB --- 2012-08-20 11:49:21 - /usr/sbin/config -m CAMBRIA TB --- 2012-08-20 11:49:21 - skipping CAMBRIA kernel TB --- 2012-08-20 11:49:21 - cd /src/sys/arm/conf TB --- 2012-08-20 11:49:21 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-08-20 11:49:21 - building CNS11XXNAS kernel TB --- 2012-08-20 11:49:21 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:49:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:49:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:49:21 - SRCCONF=/dev/null TB --- 2012-08-20 11:49:21 - TARGET=arm TB --- 2012-08-20 11:49:21 - TARGET_ARCH=arm TB --- 2012-08-20 11:49:21 - TZ=UTC TB --- 2012-08-20 11:49:21 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:49:21 - cd /src TB --- 2012-08-20 11:49:21 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Aug 20 11:49:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Mon Aug 20 11:51:49 UTC 2012 TB --- 2012-08-20 11:51:49 - cd /src/sys/arm/conf TB --- 2012-08-20 11:51:49 - /usr/sbin/config -m CRB TB --- 2012-08-20 11:51:49 - skipping CRB kernel TB --- 2012-08-20 11:51:49 - cd /src/sys/arm/conf TB --- 2012-08-20 11:51:49 - /usr/sbin/config -m DB-78XXX TB --- 2012-08-20 11:51:49 - building DB-78XXX kernel TB --- 2012-08-20 11:51:49 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:51:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:51:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:51:49 - SRCCONF=/dev/null TB --- 2012-08-20 11:51:49 - TARGET=arm TB --- 2012-08-20 11:51:49 - TARGET_ARCH=arm TB --- 2012-08-20 11:51:49 - TZ=UTC TB --- 2012-08-20 11:51:49 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:51:49 - cd /src TB --- 2012-08-20 11:51:49 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Aug 20 11:51:49 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Mon Aug 20 11:54:38 UTC 2012 TB --- 2012-08-20 11:54:38 - cd /src/sys/arm/conf TB --- 2012-08-20 11:54:38 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-08-20 11:54:38 - building DB-88F5XXX kernel TB --- 2012-08-20 11:54:38 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:54:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:54:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:54:38 - SRCCONF=/dev/null TB --- 2012-08-20 11:54:38 - TARGET=arm TB --- 2012-08-20 11:54:38 - TARGET_ARCH=arm TB --- 2012-08-20 11:54:38 - TZ=UTC TB --- 2012-08-20 11:54:38 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:54:38 - cd /src TB --- 2012-08-20 11:54:38 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Mon Aug 20 11:54:38 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Mon Aug 20 11:57:20 UTC 2012 TB --- 2012-08-20 11:57:20 - cd /src/sys/arm/conf TB --- 2012-08-20 11:57:20 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-08-20 11:57:21 - building DB-88F6XXX kernel TB --- 2012-08-20 11:57:21 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 11:57:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 11:57:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 11:57:21 - SRCCONF=/dev/null TB --- 2012-08-20 11:57:21 - TARGET=arm TB --- 2012-08-20 11:57:21 - TARGET_ARCH=arm TB --- 2012-08-20 11:57:21 - TZ=UTC TB --- 2012-08-20 11:57:21 - __MAKE_CONF=/dev/null TB --- 2012-08-20 11:57:21 - cd /src TB --- 2012-08-20 11:57:21 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Mon Aug 20 11:57:21 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Mon Aug 20 12:00:16 UTC 2012 TB --- 2012-08-20 12:00:16 - cd /src/sys/arm/conf TB --- 2012-08-20 12:00:16 - /usr/sbin/config -m DOCKSTAR TB --- 2012-08-20 12:00:16 - building DOCKSTAR kernel TB --- 2012-08-20 12:00:16 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 12:00:16 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 12:00:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 12:00:16 - SRCCONF=/dev/null TB --- 2012-08-20 12:00:16 - TARGET=arm TB --- 2012-08-20 12:00:16 - TARGET_ARCH=arm TB --- 2012-08-20 12:00:16 - TZ=UTC TB --- 2012-08-20 12:00:16 - __MAKE_CONF=/dev/null TB --- 2012-08-20 12:00:16 - cd /src TB --- 2012-08-20 12:00:16 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Mon Aug 20 12:00:16 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Mon Aug 20 12:02:52 UTC 2012 TB --- 2012-08-20 12:02:52 - cd /src/sys/arm/conf TB --- 2012-08-20 12:02:52 - /usr/sbin/config -m EA3250 TB --- 2012-08-20 12:02:52 - building EA3250 kernel TB --- 2012-08-20 12:02:52 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 12:02:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 12:02:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 12:02:52 - SRCCONF=/dev/null TB --- 2012-08-20 12:02:52 - TARGET=arm TB --- 2012-08-20 12:02:52 - TARGET_ARCH=arm TB --- 2012-08-20 12:02:52 - TZ=UTC TB --- 2012-08-20 12:02:52 - __MAKE_CONF=/dev/null TB --- 2012-08-20 12:02:52 - cd /src TB --- 2012-08-20 12:02:52 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Mon Aug 20 12:02:52 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Mon Aug 20 12:05:30 UTC 2012 TB --- 2012-08-20 12:05:30 - cd /src/sys/arm/conf TB --- 2012-08-20 12:05:30 - /usr/sbin/config -m EB9200 TB --- 2012-08-20 12:05:30 - building EB9200 kernel TB --- 2012-08-20 12:05:30 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 12:05:30 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 12:05:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 12:05:30 - SRCCONF=/dev/null TB --- 2012-08-20 12:05:30 - TARGET=arm TB --- 2012-08-20 12:05:30 - TARGET_ARCH=arm TB --- 2012-08-20 12:05:30 - TZ=UTC TB --- 2012-08-20 12:05:30 - __MAKE_CONF=/dev/null TB --- 2012-08-20 12:05:30 - cd /src TB --- 2012-08-20 12:05:30 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Mon Aug 20 12:05:31 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Mon Aug 20 12:08:01 UTC 2012 TB --- 2012-08-20 12:08:01 - cd /src/sys/arm/conf TB --- 2012-08-20 12:08:01 - /usr/sbin/config -m EP80219 TB --- 2012-08-20 12:08:01 - skipping EP80219 kernel TB --- 2012-08-20 12:08:01 - cd /src/sys/arm/conf TB --- 2012-08-20 12:08:01 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-08-20 12:08:01 - building ETHERNUT5 kernel TB --- 2012-08-20 12:08:01 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 12:08:01 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 12:08:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 12:08:01 - SRCCONF=/dev/null TB --- 2012-08-20 12:08:01 - TARGET=arm TB --- 2012-08-20 12:08:01 - TARGET_ARCH=arm TB --- 2012-08-20 12:08:01 - TZ=UTC TB --- 2012-08-20 12:08:01 - __MAKE_CONF=/dev/null TB --- 2012-08-20 12:08:01 - cd /src TB --- 2012-08-20 12:08:01 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Mon Aug 20 12:08:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_chaindesclist': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:379: error: 'ATH_DEBUG_XMIT' undeclared (first use in this function) /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:379: error: (Each undeclared identifier is reported only once /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:379: error: for each function it appears in.) cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:380: warning: implicit declaration of function 'ath_printtxbuf' /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:380: warning: nested extern declaration of 'ath_printtxbuf' [-Wnested-externs] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-20 12:12:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-20 12:12:31 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-08-20 12:12:31 - 3844.17 user 789.78 system 5551.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 18:30:33 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF6ED10656A8; Mon, 20 Aug 2012 18:30:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8E84A8FC19; Mon, 20 Aug 2012 18:30:33 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id q7KIUWkg077046; Mon, 20 Aug 2012 14:30:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q7KIUWwt077045; Mon, 20 Aug 2012 18:30:32 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 20 Aug 2012 18:30:32 GMT Message-Id: <201208201830.q7KIUWwt077045@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:30:34 -0000 TB --- 2012-08-20 16:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-08-20 16:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-20 16:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-08-20 16:50:00 - cleaning the object tree TB --- 2012-08-20 16:56:30 - cvsupping the source tree TB --- 2012-08-20 16:56:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-08-20 16:59:05 - building world TB --- 2012-08-20 16:59:05 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 16:59:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 16:59:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 16:59:05 - SRCCONF=/dev/null TB --- 2012-08-20 16:59:05 - TARGET=arm TB --- 2012-08-20 16:59:05 - TARGET_ARCH=arm TB --- 2012-08-20 16:59:05 - TZ=UTC TB --- 2012-08-20 16:59:05 - __MAKE_CONF=/dev/null TB --- 2012-08-20 16:59:05 - cd /src TB --- 2012-08-20 16:59:05 - /usr/bin/make -B buildworld >>> World build started on Mon Aug 20 16:59:06 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Aug 20 18:01:33 UTC 2012 TB --- 2012-08-20 18:01:33 - cd /src/sys/arm/conf TB --- 2012-08-20 18:01:33 - /usr/sbin/config -m ARMADAXP TB --- 2012-08-20 18:01:34 - skipping ARMADAXP kernel TB --- 2012-08-20 18:01:34 - cd /src/sys/arm/conf TB --- 2012-08-20 18:01:34 - /usr/sbin/config -m ATMEL TB --- 2012-08-20 18:01:34 - building ATMEL kernel TB --- 2012-08-20 18:01:34 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:01:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:01:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:01:34 - SRCCONF=/dev/null TB --- 2012-08-20 18:01:34 - TARGET=arm TB --- 2012-08-20 18:01:34 - TARGET_ARCH=arm TB --- 2012-08-20 18:01:34 - TZ=UTC TB --- 2012-08-20 18:01:34 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:01:34 - cd /src TB --- 2012-08-20 18:01:34 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Mon Aug 20 18:01:34 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Mon Aug 20 18:05:05 UTC 2012 TB --- 2012-08-20 18:05:05 - cd /src/sys/arm/conf TB --- 2012-08-20 18:05:05 - /usr/sbin/config -m AVILA TB --- 2012-08-20 18:05:06 - skipping AVILA kernel TB --- 2012-08-20 18:05:06 - cd /src/sys/arm/conf TB --- 2012-08-20 18:05:06 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-08-20 18:05:06 - skipping BEAGLEBONE kernel TB --- 2012-08-20 18:05:06 - cd /src/sys/arm/conf TB --- 2012-08-20 18:05:06 - /usr/sbin/config -m BWCT TB --- 2012-08-20 18:05:06 - building BWCT kernel TB --- 2012-08-20 18:05:06 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:05:06 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:05:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:05:06 - SRCCONF=/dev/null TB --- 2012-08-20 18:05:06 - TARGET=arm TB --- 2012-08-20 18:05:06 - TARGET_ARCH=arm TB --- 2012-08-20 18:05:06 - TZ=UTC TB --- 2012-08-20 18:05:06 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:05:06 - cd /src TB --- 2012-08-20 18:05:06 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Aug 20 18:05:06 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Aug 20 18:07:15 UTC 2012 TB --- 2012-08-20 18:07:15 - cd /src/sys/arm/conf TB --- 2012-08-20 18:07:15 - /usr/sbin/config -m CAMBRIA TB --- 2012-08-20 18:07:15 - skipping CAMBRIA kernel TB --- 2012-08-20 18:07:15 - cd /src/sys/arm/conf TB --- 2012-08-20 18:07:15 - /usr/sbin/config -m CNS11XXNAS TB --- 2012-08-20 18:07:15 - building CNS11XXNAS kernel TB --- 2012-08-20 18:07:15 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:07:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:07:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:07:15 - SRCCONF=/dev/null TB --- 2012-08-20 18:07:15 - TARGET=arm TB --- 2012-08-20 18:07:15 - TARGET_ARCH=arm TB --- 2012-08-20 18:07:15 - TZ=UTC TB --- 2012-08-20 18:07:15 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:07:15 - cd /src TB --- 2012-08-20 18:07:15 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Aug 20 18:07:15 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Mon Aug 20 18:09:42 UTC 2012 TB --- 2012-08-20 18:09:42 - cd /src/sys/arm/conf TB --- 2012-08-20 18:09:42 - /usr/sbin/config -m CRB TB --- 2012-08-20 18:09:42 - skipping CRB kernel TB --- 2012-08-20 18:09:42 - cd /src/sys/arm/conf TB --- 2012-08-20 18:09:42 - /usr/sbin/config -m DB-78XXX TB --- 2012-08-20 18:09:42 - building DB-78XXX kernel TB --- 2012-08-20 18:09:42 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:09:42 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:09:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:09:42 - SRCCONF=/dev/null TB --- 2012-08-20 18:09:42 - TARGET=arm TB --- 2012-08-20 18:09:42 - TARGET_ARCH=arm TB --- 2012-08-20 18:09:42 - TZ=UTC TB --- 2012-08-20 18:09:42 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:09:42 - cd /src TB --- 2012-08-20 18:09:42 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Aug 20 18:09:42 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-78XXX completed on Mon Aug 20 18:12:33 UTC 2012 TB --- 2012-08-20 18:12:33 - cd /src/sys/arm/conf TB --- 2012-08-20 18:12:33 - /usr/sbin/config -m DB-88F5XXX TB --- 2012-08-20 18:12:33 - building DB-88F5XXX kernel TB --- 2012-08-20 18:12:33 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:12:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:12:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:12:33 - SRCCONF=/dev/null TB --- 2012-08-20 18:12:33 - TARGET=arm TB --- 2012-08-20 18:12:33 - TARGET_ARCH=arm TB --- 2012-08-20 18:12:33 - TZ=UTC TB --- 2012-08-20 18:12:33 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:12:33 - cd /src TB --- 2012-08-20 18:12:33 - /usr/bin/make -B buildkernel KERNCONF=DB-88F5XXX >>> Kernel build for DB-88F5XXX started on Mon Aug 20 18:12:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F5XXX completed on Mon Aug 20 18:15:14 UTC 2012 TB --- 2012-08-20 18:15:14 - cd /src/sys/arm/conf TB --- 2012-08-20 18:15:14 - /usr/sbin/config -m DB-88F6XXX TB --- 2012-08-20 18:15:14 - building DB-88F6XXX kernel TB --- 2012-08-20 18:15:14 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:15:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:15:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:15:14 - SRCCONF=/dev/null TB --- 2012-08-20 18:15:14 - TARGET=arm TB --- 2012-08-20 18:15:14 - TARGET_ARCH=arm TB --- 2012-08-20 18:15:14 - TZ=UTC TB --- 2012-08-20 18:15:14 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:15:14 - cd /src TB --- 2012-08-20 18:15:14 - /usr/bin/make -B buildkernel KERNCONF=DB-88F6XXX >>> Kernel build for DB-88F6XXX started on Mon Aug 20 18:15:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DB-88F6XXX completed on Mon Aug 20 18:18:08 UTC 2012 TB --- 2012-08-20 18:18:08 - cd /src/sys/arm/conf TB --- 2012-08-20 18:18:08 - /usr/sbin/config -m DOCKSTAR TB --- 2012-08-20 18:18:08 - building DOCKSTAR kernel TB --- 2012-08-20 18:18:08 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:18:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:18:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:18:08 - SRCCONF=/dev/null TB --- 2012-08-20 18:18:08 - TARGET=arm TB --- 2012-08-20 18:18:08 - TARGET_ARCH=arm TB --- 2012-08-20 18:18:08 - TZ=UTC TB --- 2012-08-20 18:18:08 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:18:08 - cd /src TB --- 2012-08-20 18:18:08 - /usr/bin/make -B buildkernel KERNCONF=DOCKSTAR >>> Kernel build for DOCKSTAR started on Mon Aug 20 18:18:08 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for DOCKSTAR completed on Mon Aug 20 18:20:46 UTC 2012 TB --- 2012-08-20 18:20:46 - cd /src/sys/arm/conf TB --- 2012-08-20 18:20:46 - /usr/sbin/config -m EA3250 TB --- 2012-08-20 18:20:46 - building EA3250 kernel TB --- 2012-08-20 18:20:46 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:20:46 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:20:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:20:46 - SRCCONF=/dev/null TB --- 2012-08-20 18:20:46 - TARGET=arm TB --- 2012-08-20 18:20:46 - TARGET_ARCH=arm TB --- 2012-08-20 18:20:46 - TZ=UTC TB --- 2012-08-20 18:20:46 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:20:46 - cd /src TB --- 2012-08-20 18:20:46 - /usr/bin/make -B buildkernel KERNCONF=EA3250 >>> Kernel build for EA3250 started on Mon Aug 20 18:20:47 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EA3250 completed on Mon Aug 20 18:23:26 UTC 2012 TB --- 2012-08-20 18:23:26 - cd /src/sys/arm/conf TB --- 2012-08-20 18:23:26 - /usr/sbin/config -m EB9200 TB --- 2012-08-20 18:23:26 - building EB9200 kernel TB --- 2012-08-20 18:23:26 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:23:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:23:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:23:26 - SRCCONF=/dev/null TB --- 2012-08-20 18:23:26 - TARGET=arm TB --- 2012-08-20 18:23:26 - TARGET_ARCH=arm TB --- 2012-08-20 18:23:26 - TZ=UTC TB --- 2012-08-20 18:23:26 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:23:26 - cd /src TB --- 2012-08-20 18:23:26 - /usr/bin/make -B buildkernel KERNCONF=EB9200 >>> Kernel build for EB9200 started on Mon Aug 20 18:23:26 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for EB9200 completed on Mon Aug 20 18:25:57 UTC 2012 TB --- 2012-08-20 18:25:57 - cd /src/sys/arm/conf TB --- 2012-08-20 18:25:57 - /usr/sbin/config -m EP80219 TB --- 2012-08-20 18:25:57 - skipping EP80219 kernel TB --- 2012-08-20 18:25:57 - cd /src/sys/arm/conf TB --- 2012-08-20 18:25:57 - /usr/sbin/config -m ETHERNUT5 TB --- 2012-08-20 18:25:57 - building ETHERNUT5 kernel TB --- 2012-08-20 18:25:57 - CROSS_BUILD_TESTING=YES TB --- 2012-08-20 18:25:57 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-20 18:25:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-20 18:25:57 - SRCCONF=/dev/null TB --- 2012-08-20 18:25:57 - TARGET=arm TB --- 2012-08-20 18:25:57 - TARGET_ARCH=arm TB --- 2012-08-20 18:25:57 - TZ=UTC TB --- 2012-08-20 18:25:57 - __MAKE_CONF=/dev/null TB --- 2012-08-20 18:25:57 - cd /src TB --- 2012-08-20 18:25:57 - /usr/bin/make -B buildkernel KERNCONF=ETHERNUT5 >>> Kernel build for ETHERNUT5 started on Mon Aug 20 18:25:57 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_debug.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_keycache.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_sysctl.c cc -O -pipe -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/arm.arm/src/sys/ETHERNUT5/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/arm.arm/src/sys/ETHERNUT5 -mcpu=arm9 -ffreestanding -std=iso9899:1999 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ath/../../dev/ath/if_ath_tx.c cc1: warnings being treated as errors /src/sys/modules/ath/../../dev/ath/if_ath_tx.c: In function 'ath_tx_chaindesclist': /src/sys/modules/ath/../../dev/ath/if_ath_tx.c:310: warning: unused variable 'qnum' [-Wunused-variable] *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/arm.arm/src/sys/ETHERNUT5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-20 18:30:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-20 18:30:32 - ERROR: failed to build ETHERNUT5 kernel TB --- 2012-08-20 18:30:32 - 3844.56 user 795.80 system 6032.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Aug 20 19:01:38 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A15F2106572D; Mon, 20 Aug 2012 19:01:38 +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 4892E8FC24; Mon, 20 Aug 2012 19:01:38 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B53A1B95B; Mon, 20 Aug 2012 15:01:37 -0400 (EDT) From: John Baldwin To: Ian Lepore , scottl@freebsd.org, Justin Gibbs Date: Mon, 20 Aug 2012 14:34:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120703111753.GB72292@server.rulingia.com> <1344355782.1128.186.camel@revolution.hippie.lan> <201208071406.45172.jhb@freebsd.org> In-Reply-To: <201208071406.45172.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208201434.16538.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 20 Aug 2012 15:01:37 -0400 (EDT) Cc: arm@freebsd.org, mips@freebsd.org, Peter Jeremy Subject: Re: On-stack allocation of DMA S/G lists X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 19:01:39 -0000 [ Adding Scott Long and Justin Gibbs for their input ] On Tuesday, August 07, 2012 2:06:44 pm John Baldwin wrote: > On Tuesday, August 07, 2012 12:09:42 pm Ian Lepore wrote: > > On Mon, 2012-08-06 at 10:26 -0400, John Baldwin wrote: > > > On Thursday, July 12, 2012 8:26:05 am John Baldwin wrote: > > > > On Sunday, July 08, 2012 7:05:16 am Peter Jeremy wrote: > > > > > BTW(2): Whilst studying busdma_machdep.c for arm and mips, I've > > > > > noticed they appear to potentially allocate substantial kernel stack > > > > > under some conditions as several bus_dma(9) functions include: > > > > > bus_dma_segment_t dm_segments[dmat->nsegments]; > > > > > What prevents this overflowing the kernel stack? > > > > > > > > That does seem dubious. x86 stores the array in the tag instead. > > > > > > I have an untested patch to change bus-dma on arm and mips to allocate a > > > dynamic S/G list in each DMA tag on first use instead of using on-stack > > > allocation (which I think is rather bogus). Can folks review and test this > > > patch please? Thanks. > > > > > > http://www.FreeBSD.org/~jhb/patches/arm_mips_dynamic_dma_segs.patch > > > > > > > I'm worried about changing a per-mapping-call resource to a per-dma-tag > > resource here. What prevents the situation where you have two > > bus_dmamap_load() calls in progress at the same time using different > > buffers but the same tag? > > > > I can't find anything in the docs that indicates you have to provide > > external locking of the tag for map load/unload calls, or that even > > implies the tag can be modified by a mapping operation. The lockfunc > > stuff related to creating the tag is documented as being used only > > during a deferred callback. > > Actually, I do think it is implicit that you won't do concurrent loads > on a DMA tag, though that may not be obvious. Keep in mind that this > is what x86's bus_dma has always done. For storage drivers you certainly > can't do this or risk completeing I/O requests out-of-order which can > break an upper-layer assumption in a filesystem. Note that all other > platforms do this as well, only arm and mips allocate on the stack. One thing I should note is that it is assumed that the lock specifed by the lockfunc stuff is held when you invoke bus_dmamap_load*(). > > The existing code seems to go out of its way to avoid modifying the tag > > during a mapping operation. For example, it decides at tag creation > > time whether any bounce pages might ever be needed for the tag, and if > > so it pre-sets a bounce zone in the tag, then at mapping time the bounce > > zone is protected with its own lock when it gets modified. To me this > > feels like a way to specifically avoid the need to lock or modify the > > tag during a mapping operation. > > > > Assuming that all of the foregoing is moot for some reason I've > > overlooked, then on a purely implementation level, could all the > > duplicated code to allocate the array when necessary be moved into > > bus_dmamap_load_buffer(), triggered by a NULL 'segs' pointer? > > Nope, bus_dmamap_load() doesn't know which of M_NOWAIT / M_WAITOK is > appropriate to use. > > > And just for the record, looking at the problem from an even more > > distant vantage... is there really a problem with stack-allocating the > > segments? On a 64-bit arch the struct is like 16 bytes. Typical usage > > is to allocate a tag allowing 1 or just a few segments. Is anyone > > really going to create a tag specifying hundreds of segments that would > > overflow the stack? If they try, wouldn't failing the tag create be > > good enough? > > I/O devices can allocate tags with several S/G elements. An mfi(4) tag > on i386 would use a 256 byte segments array (512 on amd64). That's not > entirely trivial. It would be worse if you couldn't depend on > dmat->nsegments and had to always allocate the full size. Presumably > though we require C99 at that point (and it requires that?). Also, we are moving to a model of using larger MAXPHYS (some places already modify FreeBSD to bump MAXPHYS up), and to looking at using direct dispatch for disk I/O rather than always bouncing requests through g_up/g_down to gain greater concurrency in the disk I/O subsystem. Both of these are going to place greater stress on the kernel stack and argue for less kernel stack use, not more. Scott noted that a 1MB I/O request can require up to 256 segments, which is 4k. That would be too much space on the stack. One other option is to move the S/G lists into the dma map structure instead of being in the tag, but to date that has not been done because it would introduce a significant amount of memory overhead. Also, I don't see a great need to allow concurrent loads within a single tag. Typically you allocate a single tag for each "thing" that can accept a stream of DMA requests (so 1 tag for each command queue on a HBA, or for each descriptor ring on a NIC). For example, in the case of a multiq NIC you want to use separate tags so that each tag uses a per-ring lock. But typically that stream of DMA requests requires serialization, so you would never end up wanting to have concurrent loads on the same tag. -- John Baldwin From owner-freebsd-arm@FreeBSD.ORG Wed Aug 22 00:13:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD04A1065673; Wed, 22 Aug 2012 00:13:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7AFCE8FC0C; Wed, 22 Aug 2012 00:13:31 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so694666pbb.13 for ; Tue, 21 Aug 2012 17:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t2HLgHXa9oavB+WXOqUY4kT13UfZ5ZTD7jfbn8MHu3I=; b=fujeCX/dcYwoZCt33HngMBA/JevOVAgHc3Py58DZbZ9bJWM6FkgOOurLKb8CJb+Vqj 2xwJtOPJKmSgdQZGTIK2CAd1uHYa1z01HRzr84ak+vzIk7aKb+kbRbNd1JHwL9ugFEtf +MiHrujbiJ4nWcYPowZz2QEyotG0cq4W3H+9GHpSbYb5/lebt1kauwQMxCOOm/nzVcAY Jx4nHy1SaHBbRr1u66KxDdbgNAQr3N7FGXYFuPS+0ZyGEN55P4HFrSiVZCKi8CfUoEbG w2axWSQ2uKUSDyGDX5KoF/gxqYbsO5vAoy8XbtqG7yDNGQklvLOemGZ84rEWi0oRy26b wqjA== MIME-Version: 1.0 Received: by 10.68.238.74 with SMTP id vi10mr25913732pbc.48.1345594411144; Tue, 21 Aug 2012 17:13:31 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.43.169 with HTTP; Tue, 21 Aug 2012 17:13:31 -0700 (PDT) In-Reply-To: <201208212344.q7LNilhA028150@svn.freebsd.org> References: <201208212344.q7LNilhA028150@svn.freebsd.org> Date: Tue, 21 Aug 2012 17:13:31 -0700 X-Google-Sender-Auth: HST_KnaFO1zrgd0R4YYcip-bb3o Message-ID: From: Adrian Chadd To: Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org Subject: Re: svn commit: r239547 - head/sys/conf X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 00:13:31 -0000 Thanks so much for this! I've just booted -HEAD (from a week or so ago, I think) on a Gateworks Cambria board (Intel xscale IXP435). Without this, the build was giving me a little-endian kernel.. Adrian On 21 August 2012 16:44, Oleksandr Tymoshenko wrote: > Author: gonzo > Date: Tue Aug 21 23:44:47 2012 > New Revision: 239547 > URL: http://svn.freebsd.org/changeset/base/239547 > > Log: > Get rid of ARM_BIG_ENDIAN for good: > - remove leftovers in Makefile.arm > - Let ld use default output format instead of providing one in ldscript > > Modified: > head/sys/conf/Makefile.arm > head/sys/conf/ldscript.arm > > Modified: head/sys/conf/Makefile.arm > ============================================================================== > --- head/sys/conf/Makefile.arm Tue Aug 21 22:42:46 2012 (r239546) > +++ head/sys/conf/Makefile.arm Tue Aug 21 23:44:47 2012 (r239547) > @@ -35,17 +35,6 @@ INCLUDES+= -I$S/contrib/libfdt > SYSTEM_LD:= ${SYSTEM_LD:$S/conf/ldscript.$M=ldscript.$M} > SYSTEM_DEP:= ${SYSTEM_DEP:$S/conf/ldscript.$M=ldscript.$M} > > -.if defined(ARM_BIG_ENDIAN) > -CC += -mbig-endian > -SYSTEM_LD += -EB > -LD += -EB > -.else > -CC += -mlittle-endian > -SYSTEM_LD += -EL > -LD += -EL > -.endif > - > - > .if !defined(DEBUG) && !defined(PROFLEVEL) > STRIP_FLAGS = -S > .endif > > Modified: head/sys/conf/ldscript.arm > ============================================================================== > --- head/sys/conf/ldscript.arm Tue Aug 21 22:42:46 2012 (r239546) > +++ head/sys/conf/ldscript.arm Tue Aug 21 23:44:47 2012 (r239547) > @@ -1,5 +1,4 @@ > /* $FreeBSD$ */ > -OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm") > OUTPUT_ARCH(arm) > ENTRY(_start) > From owner-freebsd-arm@FreeBSD.ORG Wed Aug 22 03:17:02 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 472A9106566B; Wed, 22 Aug 2012 03:17:02 +0000 (UTC) (envelope-from gnn@freebsd.org) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 138178FC1C; Wed, 22 Aug 2012 03:17:01 +0000 (UTC) Received: from pool-96-250-5-62.nycmny.fios.verizon.net ([96.250.5.62]:57620 helo=minion.home) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1T41RE-0005HT-Qb; Tue, 21 Aug 2012 23:17:01 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: George Neville-Neil In-Reply-To: Date: Tue, 21 Aug 2012 23:17:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> To: Oleksandr Tymoshenko X-Mailer: Apple Mail (2.1485) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freebsd.org Cc: arm@freebsd.org, arch@freebsd.org, hackers@freebsd.org Subject: Re: projects/armv6 merged to HEAD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 03:17:02 -0000 On Aug 17, 2012, at 05:24 , Robert Watson wrote: >=20 > On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: >=20 >> projects/armv6 branch was merged to HEAD and should be considered = dead now. This patch is a result of a joint effort by many people. = Including but not limited to: >=20 > Amazing work -- many thanks are due to to everyone who was involved! >=20 And this ought to simplify work on both the Rasberry Pi and BeagleBone, = as well as the rest of the arm systems. Great! Best, George From owner-freebsd-arm@FreeBSD.ORG Wed Aug 22 10:39:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3AD601065672; Wed, 22 Aug 2012 10:39:18 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) by mx1.freebsd.org (Postfix) with ESMTP id BE0E08FC08; Wed, 22 Aug 2012 10:39:17 +0000 (UTC) Received: from [194.32.164.22] (80-46-130-69.static.dsl.as9105.com [80.46.130.69]) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id q7MAdB08011468; Wed, 22 Aug 2012 11:39:11 +0100 (BST) (envelope-from rb@gid.co.uk) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Bob Bishop In-Reply-To: <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> Date: Wed, 22 Aug 2012 11:39:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3440928F-900B-4894-BCFE-5E738B644D59@gid.co.uk> References: <8B16B6D3-A9C1-487E-9C42-6EDD07D689D4@freebsd.org> <2533EA82-0ACA-48B1-B56D-A3B922A02CF3@freebsd.org> To: George Neville-Neil X-Mailer: Apple Mail (2.1278) Cc: arm@freebsd.org, Oleksandr Tymoshenko , hackers@freebsd.org, arch@freebsd.org Subject: Re: projects/armv6 merged to HEAD X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 10:39:18 -0000 On 22 Aug 2012, at 04:17, George Neville-Neil wrote: >=20 > On Aug 17, 2012, at 05:24 , Robert Watson wrote: >=20 >>=20 >> On Thu, 16 Aug 2012, Oleksandr Tymoshenko wrote: >>=20 >>> projects/armv6 branch was merged to HEAD and should be considered = dead now. This patch is a result of a joint effort by many people. = Including but not limited to: >>=20 >> Amazing work -- many thanks are due to to everyone who was involved! >>=20 >=20 > And this ought to simplify work on both the Rasberry Pi and = BeagleBone, as well as the > rest of the arm systems. Great! What he said. Big thanks to all concerned! -- Bob Bishop rb@gid.co.uk From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 21:28:29 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D810106564A for ; Thu, 23 Aug 2012 21:28:29 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1068FC16 for ; Thu, 23 Aug 2012 21:28:29 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta03.emeryville.ca.mail.comcast.net with comcast id qGNu1j0070cQ2SLA3MUP9x; Thu, 23 Aug 2012 21:28:23 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta10.emeryville.ca.mail.comcast.net with comcast id qMUN1j00P4NgCEG8WMUPgg; Thu, 23 Aug 2012 21:28:23 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NLSK2M025408; Thu, 23 Aug 2012 15:28:20 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-arch@freebsd.org, freebsd-mips@freebsd.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 15:28:20 -0600 Message-ID: <1345757300.27688.535.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:28:29 -0000 A recent innocuous change to the USB driver code caused intermittant errors in the umass(4) driver on ARM and MIPS platforms, and this message is some background on partial cacheline flushes, and info on what I found while investigating the cause, which is rooted in the DMA cache coherency code. First I need to say that when I say ARM in this message I mean "ARM and MIPS and any other platform where cache coherency around DMA operations is maintained with help from software (as opposed to being implemented purely in hardware as it is in i386/amd64)." I have no experience on MIPS, but I believe that it's similar to ARM in regards to cache coherency. As far as I know, this is not specific to VIVT caches, but rather is specific to software cache coherency, so it probably applies to armv6/v7 as well as v4 and v5 that I'm working with. Over the years, we've had a series of glitches and patches in the partial cacheline flush logic for arm. Even with all the fixes, I've thought that there are two ways that the scheme could fail, but I've never been able to demonstrate it experimentally, and empirically it seems that the failures are rare. Both ways involve the fact that we have several software entities trying to maintain the caches concurrently, without knowledge of each others' actions or needs. The two ways are basically two variations of a situation where a dirty cacheline is flushed by the software while a DMA operation that overlaps that cacheline is in progress: * A cpu_dcache_wbinv_all() call happens after some DMA data has hit main memory, but before bus_dmamap_sync(POSTREAD) is called. * Two independent DMA operations are happening in different parts of the same cacheline and some DMA data from both devices has hit main memory; whichever operation does the POSTREAD sync first can wipe out data in main memory from the other operation that is still in progress. For problems to happen, the CPU has to also modify the same memory location / cacheline as the DMA, so that the cache holds the newest data for part of the cacheline, and main memory holds the newest data for part of the cacheline. Our logic for handling POSTREAD partial cacheline flushes creates this condition even if it doesn't already exist on entry to the sync routine. The wbinv_all() situation seemed to me the most likely to occur. It gets called from a variety of places for a variety of reasons. It is called from a several places in pmap.c; it appears to me that many of those invocations can happen at completely arbitrary points with respect to any IO that's in progress. Another way wbinv_all() can get invoked is during a call to wbinv_range() or even just inv_range(), when the range to be invalidated is so large that it's too inefficient to loop through the range discarding a line at a time on a given platform. In those cases, for some arm platforms, the inv_range() implementation just calls wbinv_all() internally. The implication of the last paragraph is that wbinv_all() can potentially be invoked as part of the busdma sync operations for any IO, PREREAD, PREWRITE, or POSTREAD, from any device at any time. A recent USB driver change moved some things around in memory, such that a small (13 byte) IO buffer became split across two cachelines, and suddenly we had intermittant (but fairly frequent) failures reported by umass(4). Some logging from the usb driver showed that there was stale data from previous IO operations in part of the IO buffer. I added some code to pre-initialize the buffer to various byte patterns before starting the IO, and after the IO, part of the buffer would contain those patterns, and the rest of the buffer (after the cacheline split point) contained newer data from the IO. It looked pretty conclusively as if the partial cacheline flush logic was failing. First I investigated the logic for handling such splits, but it was working correctly. So I moved on to assuming that the cause was one of the two potential problems I've long suspected. I received a helpful clue from Hans that the buffer in question was allocated once at device creation and remained allocated from that point on. That made it easy to save that buffer pointer when it was created, and write wrappers for all the cache writeback and invalidate routines that checked whether the cacheline containing that buffer was part of the cache operation. What I expected to see was that USB would call the busdma sync ops before starting the IO, and then before it called the post-IO sync ops I would see that something else in the system called wbinv_all() or a [wb]inv_range() that included the umass buffer address. What I actually saw was that that never happened. Not even once. Very rarely I would see some other [wb]inv_range() calls happen, but the ranges never involved the umass buffer, and the unit I'm doing these tests on (a DreamPlug) is not one that ever turns an inv_range into wbinv_all. It eventually occurred to me that I had been overlooking the most obvious way a dirty cacheline can get written back to main memory: the cache hardware needs to evict a line to make room for a new incoming line, and the line it has chosen is dirty and has to be written back before being evicted. Unfortunately, there is no way to instrument the software to detect that happening, so now I'm in the position of proving something based on the complete lack of evidence that anything else is the cause. That's a great way to promote a conspiracy theory, not so great for debugging. In addition to showing that no software-triggered flush/invalidate operations are affecting the cacheline, I was able to show that the problem wasn't just that a partial cacheline flush was involved, but that error condition depended on the specific memory addresses (and thus the specific cacheline) involved. At the point in the usb code where that buffer is allocated I changed the code to add 32 bytes to the buffer offset, so that the buffer is still split across two cachelines in exactly the same way as before, but now it's two different cachelines. When doing this, the error doesn't occur. I think that may lend some weight to the theory that it is hardware-based cacheline eviction which is causing a flush of a dirty cacheline while IO into that memory is in progress, but it's just more circumstantial evidence. I think the intermittant-but-frequent nature of the error may also be circumstantial evidence that hardware eviction is the cause. My DreamPlug unit has a 4-way set-associative cache that selects one of the ways at random when it needs to evict a line for refill. That would seem to imply that there's a one in four chance that the cacheline holding the umass status buffer is the one that gets hit, and that seems to match the symptoms I see of "this usb drive kind of works but there are tons of errors spewing on the console about it". Sometimes you get several failures in a row and the drive fails to attach, but most of the time it limps along with lots of errors followed by succesful retries. I considered trying to lock the cacheline in question into the cache as a way of confirming this situation (that should make the error go away). It turns out that's not especially easy to do on this platform, and you can't lock a single cacheline, you have to lock a whole cache way. That's a pretty big change that will perturb system operations in general, it may be hard to draw conclusions from the results. The ARM Architecture Reference Manual mentions the following guidelines as part of the strategy for handling DMA/cache coherency: * marking the memory areas involved in the DMA operation as uncachable and/or unbufferable * cleaning and/or invalidating the data cache, at least with respect to the address range involved in the DMA operation * draining the write buffer * restrictions on processor accesses to the address range involved in the DMA operation until it is known that the DMA operation is complete. Our partial cacheline flush logic is trying to wish away the last bullet item, but now I think we can never successfully do so. Until last week I thought we had a theoretical problem that could eventually be fixed with a sufficiently-clever cache maintenance implementation that somehow avoided having unrelated parts of the OS interfering with each other's operations. Now it appears that hardware operations we have no direct control over can also lead to memory corruption, and no amount of software cleverness is ever going to allow concurrent CPU and DMA access to the same memory without disabling the cache for that memory range. At this point I was going to launch into some "what we can do about it" rambling, but this is long enough already; I think I'll leave this message as a summary of where we've come from and what I learned in the past few days, and leave "what next" for followups. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 21:50:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07F2E1065674 for ; Thu, 23 Aug 2012 21:50:39 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id C2CE58FC15 for ; Thu, 23 Aug 2012 21:50:38 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2300537pbb.13 for ; Thu, 23 Aug 2012 14:50:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=WSYlzD3T5FYG0E17Iqr7sZ9KknY3rYR8v2QRn3PxG8E=; b=iQUXtFwBUMAgz8F7SyvZGbHoirdNf5Pqpr/DMRbGIQVyHm2uDljFrcnop4CYMv2dk8 lPJ7zKQRZJRPNrt+4gtx7Tm6srzJsELYnBK/HszXBaSDyfrXFq/LXSTq4u9g0EGgJXK2 MY6X8syJun5b4aff1KZ7ZhvGP4Jfk2RnjB/QTwsgqm3PccV2S+cagv35IEZwYmw/+POs L1SYSUbm60Ptg1UCPTjy6Y70teiNygZylHvHpcwB7lbdlcgbR2Y8vSq91y2JW81lkq9B 7vNHmGz4vcOnReXUy3HL/sQPqlRcYOh6l9F66GQ0KfaHjx91Kf68OOssXPUgBzzfeSSU biaA== Received: by 10.66.80.193 with SMTP id t1mr6152901pax.69.1345758638309; Thu, 23 Aug 2012 14:50:38 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id gf3sm6757324pbc.74.2012.08.23.14.50.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 14:50:37 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345757300.27688.535.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 15:50:35 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnADOSUgHV+GIjW9GnMjmnflvrgMTYHCqfB9By6Fq6t3/loVP2BgOccRDZqZhw12ycYWNuH Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 21:50:39 -0000 On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: > A recent innocuous change to the USB driver code caused intermittant > errors in the umass(4) driver on ARM and MIPS platforms, and this I think the proper solution is to segregate DMA and non-DMA parts of = structures so that you don't have both sharing a cache line. I also wonder why we don't allocate the DMA memory for these structures = separately from the non-DMA parts. This would eliminate the = USB_CACHE_BYTES kludge (which is CPU dependent, not arch dependent) and = move the knowledge of this junk into busdma layer where it belongs. = =46rom my understanding of the issue, this would completely eliminate = the problem forever! Sharing a cacheline between something that is DMA aware and something = that is just begging for trouble. We're doing more work than we need = to to support this dubious feature and we'd be miles ahead if we could = not share at all. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 22:55:52 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7569F106566B; Thu, 23 Aug 2012 22:55:52 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 55DC28FC16; Thu, 23 Aug 2012 22:55:51 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 758C456252; Thu, 23 Aug 2012 17:55:50 -0500 (CDT) Date: Thu, 23 Aug 2012 17:55:50 -0500 From: Mark Linimon To: freebsd-ports@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <20120823225550.GA13223@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: linimon@FreeBSD.org Subject: announcing the availability of packages for the Arm architecture X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 22:55:52 -0000 With the help of Alexander Motin, I have now started limited package builds on the Arm architecture. Right now builds are only being done for a few hand-selected ports, and only on arm-9 with pkgng. No builds with the old pkg_* tools are intended at this time. For those of you with Arm systems, you should be able to install packages just by setting USE_PKGNG="yes" in /etc/make.conf and then using pkg(8). There are more details at http://wiki.freebsd.org/PackagesOnArm . Please let me know if how these packages work out for you. Thanks. mcl From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:09:55 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB858106566B; Thu, 23 Aug 2012 23:09:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B2EEE8FC16; Thu, 23 Aug 2012 23:09:55 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2387126pbb.13 for ; Thu, 23 Aug 2012 16:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lPP5YvtAv3fjOFO37wLOSmHkqwKO0tRK39RRHX3KsdA=; b=iJlel0NdvHa0pb0YIuPboM2W+Rhof6sYq13DQpJWAFdf6lK+rJ5UaFiLI+eYNL7Q1h uqaT7qobOE4KQkVME6sDZV2/NaWe2eFrX6VP1YWOUw41MY5mf4sneuJNr4sscZMIiEGm wRkDb3DXJcY+Uj4x3p4A1gRJHMSw6UQNlIU3CvJ2vvecgXvW5nzwmwRe5Hv2gGsIlwWl L7evO1FlXhUm3hEt/RrblcgQpJmFvp/Kcq2GLYMmIKsSIBFkCijwlha/McepSbcOowMD kMSao4x61/eWBKHA36z7yml0i9E9dHQR+dmw3ddp0iu4WSaD+Ugid52ev7CrW2OsBozE 59ww== MIME-Version: 1.0 Received: by 10.66.78.73 with SMTP id z9mr6742852paw.9.1345763395120; Thu, 23 Aug 2012 16:09:55 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 16:09:55 -0700 (PDT) In-Reply-To: <1345757300.27688.535.camel@revolution.hippie.lan> References: <1345757300.27688.535.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 16:09:55 -0700 X-Google-Sender-Auth: knDTxNAgW4qmvzZwfhemm3Ea6BQ Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:09:56 -0000 [snip] Whoa, there's USB code that has these small buffers straddle cache lines? Why aren't they just allocated to always be in their own separate buffers, so they don't ever have to worry about overlapping cache lines? Adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:10:14 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2675E10656DB for ; Thu, 23 Aug 2012 23:10:14 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id 653448FC12 for ; Thu, 23 Aug 2012 23:10:02 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta05.emeryville.ca.mail.comcast.net with comcast id qMjG1j00716AWCUA5P9we1; Thu, 23 Aug 2012 23:09:56 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta06.emeryville.ca.mail.comcast.net with comcast id qP9v1j00g4NgCEG8SP9ws5; Thu, 23 Aug 2012 23:09:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NN9spk025527; Thu, 23 Aug 2012 17:09:54 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-arch@freebsd.org, freebsd-arm@freebsd.org, freebsd-mips@freebsd.org In-Reply-To: <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 17:09:53 -0600 Message-ID: <1345763393.27688.578.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:10:14 -0000 On Thu, 2012-08-23 at 15:50 -0600, Warner Losh wrote: > On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: > > A recent innocuous change to the USB driver code caused intermittant > > errors in the umass(4) driver on ARM and MIPS platforms, and this > > I think the proper solution is to segregate DMA and non-DMA parts of structures so that you don't have both sharing a cache line. > > I also wonder why we don't allocate the DMA memory for these structures separately from the non-DMA parts. This would eliminate the USB_CACHE_BYTES kludge (which is CPU dependent, not arch dependent) and move the knowledge of this junk into busdma layer where it belongs. From my understanding of the issue, this would completely eliminate the problem forever! > > Sharing a cacheline between something that is DMA aware and something that is just begging for trouble. We're doing more work than we need to to support this dubious feature and we'd be miles ahead if we could not share at all. > > Warner > It seems to me that what we have here is a new type of constraint on DMA operations, and we need a way to communicate that constraint from the part of the platform support code that knows about it to the drivers and driver support code that needs to know. The way we communicate DMA constraints is with a busdma tag, but right now that tag only communicates constraints that were needed for ISA and PCI busses, namely buffer alignment, boundary-crossing restrictions, and exclusion regions. Now we have a new type of constraint, I think of it as "granularity". In effect, we have a DMA system that can only do DMA in cacheline sized chunks. Even when the IO size -- and thus the number of "bits on the wire" -- is less than the cacheline size, at the end of the DMA operation (which includes the software-assisted coherency operations) the number of bytes in memory that may be modified is the size of a cacheline. This is because "the DMA system" is not just the engine that moves bytes around, it's the combination of hardware and software that work together to maintain cache coherency. Ideally we'd find a way to communicate this new constraint using the existing mechanism, the busdma tag, and ideally we'd not have to change every existing call to bus_dma_tag_create() to add a new parm. As I understand it, parent tags are now passed down through the newbus hierarchy consistantly, such that a tag at the nexus level could describe a platform requirement such as granularity, and all devices and the helper code they use will have access to that constraint via inheritance from ancestors' tags. Maybe we could have a new flavor of bus_dma_tag_create() that takes a struct of parms, and existing calls wouldn't have to be changed. Communicating the constraint is only part of the problem; it also has to be easy for drivers to work with that constraint, especially drivers that are not targeted specifically at platforms with granular DMA. I think we can achieve a huge chunk of that purely within the arm/mips implementation of bus_dmamem_alloc(), but even so there would be a new conceptual limitation on using that routine: it is specifically for allocating DMA buffers, and that means that there will be a new a rule that the CPU cannot access any memory within that buffer while an IO operation is in progress. I'd also like to say there's a new rule that you cannot subdivide a buffer obtained from bus_dmamem_alloc() into multiple buffers, or into a combination of DMA and CPU-accessed data. That would be bad news for the USB subsystem, and perhaps other drivers. If this idea is either impossible or particularly contentious, then I guess we'd need some new helper routines so that a driver can subdivide the memory in a way that doesn't violate any constraints implied by the tag used to allocate the buffer. Not all IO occurs using buffers obtained from bus_dmamem_alloc(), and I doubt we can reasonably ever require that it be so. I think the only hope we have of handling that problem is to bounce the requests that don't meet the granularity constraint, just as we'd have to do if the caller-supplied buffer fell into an exclusion zone or violated an alignment or boundary constraint. When I've tossed this idea out in the past there was instant resistance. Yeah, bounce buffers are massively inefficient, but my experience has been that most of the IO that isn't aligned and sized to a multiple of a cacheline is small IO (a few to a few dozen bytes). I've never seen a case of page-sized or larger IO requests that required partial-cacheline handling. I'm sure some examples exist, but they're probably more the exception than the rule. (And the bad performance you'd get from bouncing and copying massive bulk data flow would be a powerful incentive to track down the culprit and improve the driver.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:21:27 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 432BF106566B for ; Thu, 23 Aug 2012 23:21:27 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id E07A78FC0A for ; Thu, 23 Aug 2012 23:21:26 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 2C53C5625B; Thu, 23 Aug 2012 18:21:26 -0500 (CDT) Date: Thu, 23 Aug 2012 18:21:26 -0500 From: Mark Linimon To: freebsd-arm@FreeBSD.org Message-ID: <20120823232126.GD13223@lonesome.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: [linimon@FreeBSD.org: ports/170946: [patch] mark certain ports broken on ARM] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:21:27 -0000 FYI ----- Forwarded message from Mark Linimon ----- Date: Thu, 23 Aug 2012 23:00:12 GMT From: Mark Linimon To: FreeBSD-gnats-submit@FreeBSD.org Cc: Subject: ports/170946: [patch] mark certain ports broken on ARM >Number: 170946 >Category: ports >Synopsis: [patch] mark certain ports broken on ARM >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-ports-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Thu Aug 23 23:10:01 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Mark Linimon >Release: FreeBSD 9.0-STABLE i386 >Organization: FreeBSD >Environment: System: FreeBSD freefall.freebsd.org 9.0-STABLE FreeBSD 9.0-STABLE #6 r235139: Tue May 8 21:19:03 UTC 2012 simon@freefall.freebsd.org:/usr/obj/usr/src/sys/FREEFALL i386 >Description: I have recently started building packages for arm. At the moment I am building a very restricted subset due to how little hardware we have. To keep from trying to build the same ports over and over, I'd like to go ahead and mark some ports from the first few runs as BROKEN. I will be testing this both on arm and in combination with some other amd64 build, but I would like to give the maintainers a heads-up. (I do not expect the maintainers to take any action on fixing the problems; just approval of the BROKEN line.) Thanks. >How-To-Repeat: >Fix: Index: databases/mysql41-server/Makefile =================================================================== --- databases/mysql41-server/Makefile (revision 303040) +++ databases/mysql41-server/Makefile (working copy) @@ -62,6 +62,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if ${ARCH} == "i386" CONFIGURE_ARGS+=--enable-assembler --with-berkeley-db .endif Index: databases/mysql50-server/Makefile =================================================================== --- databases/mysql50-server/Makefile (revision 303040) +++ databases/mysql50-server/Makefile (working copy) @@ -70,6 +70,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if ${ARCH} == "i386" CONFIGURE_ARGS+=--enable-assembler --with-berkeley-db .endif Index: databases/mysql51-server/Makefile =================================================================== --- databases/mysql51-server/Makefile (revision 303040) +++ databases/mysql51-server/Makefile (working copy) @@ -67,6 +67,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if ${ARCH} == "i386" CONFIGURE_ARGS+=--enable-assembler .endif Index: databases/mysql55-server/Makefile =================================================================== --- databases/mysql55-server/Makefile (revision 303040) +++ databases/mysql55-server/Makefile (working copy) @@ -90,4 +90,10 @@ post-patch: @${REINPLACE_CMD} 's/*.1/${MAN1}/' ${WRKSRC}/man/CMakeLists.txt -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + +.include Index: databases/py-sqlite3/Makefile =================================================================== --- databases/py-sqlite3/Makefile (revision 303040) +++ databases/py-sqlite3/Makefile (working copy) @@ -30,6 +30,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not install on arm +.endif + post-extract: .if ${PYTHON_REL} < 300 @${CP} ${FILESDIR}/setup.py ${WRKSRC} Index: devel/gobject-introspection/Makefile =================================================================== --- devel/gobject-introspection/Makefile (revision 303040) +++ devel/gobject-introspection/Makefile (working copy) @@ -42,4 +42,10 @@ @${REINPLACE_CMD} -e "s|'cc'|'${CC:Q:C/[[:space:]]+/', '/g}'|g" \ ${WRKSRC}/giscanner/sourcescanner.py -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + +.include Index: devel/icu/Makefile =================================================================== --- devel/icu/Makefile (revision 303040) +++ devel/icu/Makefile (working copy) @@ -64,6 +64,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if defined(WITHOUT_THREADS) CONFIGURE_ARGS+= --enable-threads=no .else Index: devel/llvm/Makefile =================================================================== --- devel/llvm/Makefile (revision 303040) +++ devel/llvm/Makefile (working copy) @@ -80,7 +80,9 @@ .include -.if ${ARCH} == "sparc64" +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.elif ${ARCH} == "sparc64" BROKEN= does not compile on sparc64 .endif Index: devel/nspr/Makefile =================================================================== --- devel/nspr/Makefile (revision 303040) +++ devel/nspr/Makefile (working copy) @@ -31,6 +31,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + post-patch: @${REINPLACE_CMD} -e 's,-lpthread,${PTHREAD_LIBS},g ; s,echo aout,echo elf,g' ${WRKSRC}/${CONFIGURE_SCRIPT} Index: devel/pwlib/Makefile =================================================================== --- devel/pwlib/Makefile (revision 303040) +++ devel/pwlib/Makefile (working copy) @@ -34,6 +34,9 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not install on arm: mtree +.endif CFLAGS= -O1 CONFIGURE_ENV= PTHREAD_LIBS="${PTHREAD_LIBS}" Index: devel/qmake/Makefile =================================================================== --- devel/qmake/Makefile (revision 303040) +++ devel/qmake/Makefile (working copy) @@ -62,8 +62,8 @@ .include -.if ${ARCH} == "alpha" -CXXFLAGS+= -mieee +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm .endif .include Index: devel/qt4-moc/Makefile =================================================================== --- devel/qt4-moc/Makefile (revision 303040) +++ devel/qt4-moc/Makefile (working copy) @@ -54,4 +54,10 @@ pre-build: cd ${BUILD_WRKSRC}/../bootstrap && ${MAKE} -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + +.include Index: devel/qt4-rcc/Makefile =================================================================== --- devel/qt4-rcc/Makefile (revision 303040) +++ devel/qt4-rcc/Makefile (working copy) @@ -53,4 +53,10 @@ pre-build: cd ${BUILD_WRKSRC}/../bootstrap && ${MAKE} -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not configure on arm +.endif + +.include Index: devel/qt4-uic/Makefile =================================================================== --- devel/qt4-uic/Makefile (revision 303040) +++ devel/qt4-uic/Makefile (working copy) @@ -54,4 +54,10 @@ pre-build: cd ${BUILD_WRKSRC}/../bootstrap && ${MAKE} -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not configure on arm +.endif + +.include Index: editors/emacs/Makefile =================================================================== --- editors/emacs/Makefile (revision 302835) +++ editors/emacs/Makefile (working copy) @@ -242,7 +242,9 @@ .include -.if ${ARCH} == "ia64" +.if ${ARCH} == "arm" +BROKEN= Emacs 24.X does not currently build on arm +.elif ${ARCH} == "ia64" BROKEN= Emacs 24.X does not currently build on ia64 .endif Index: graphics/cairo/Makefile =================================================================== --- graphics/cairo/Makefile (revision 303040) +++ graphics/cairo/Makefile (working copy) @@ -49,6 +49,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if defined(WITH_GL) USE_GL= gl CONFIGURE_ARGS+= --enable-gl Index: lang/gcc42/Makefile =================================================================== --- lang/gcc42/Makefile (revision 303040) +++ lang/gcc42/Makefile (working copy) @@ -40,6 +40,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if ${ARCH} == "amd64" CONFIGURE_TARGET= x86_64-portbld-freebsd${OSREL} .else Index: lang/tcl86/Makefile =================================================================== --- lang/tcl86/Makefile (revision 303040) +++ lang/tcl86/Makefile (working copy) @@ -46,6 +46,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not build on arm +.endif + .if !defined(WITHOUT_TCL_MODULES) RUN_DEPENDS+= ${LOCALBASE}/lib/tcl8/8.5/tcltest-2.3.4.tm:${PORTSDIR}/lang/tcl-modules .endif Index: mail/dovecot2/Makefile =================================================================== --- mail/dovecot2/Makefile (revision 303040) +++ mail/dovecot2/Makefile (working copy) @@ -58,6 +58,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not build on arm +.endif + # sed script for dovecot.conf REINPLACE= s!%%PROTOCOLS%%!${PROTOCOLS}!g;\ s!/usr/!${PREFIX}/!g;\ Index: mail/dovecot/Makefile =================================================================== --- mail/dovecot/Makefile (revision 303040) +++ mail/dovecot/Makefile (working copy) @@ -70,6 +70,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not build on arm +.endif + # Default requirement for dovecot rc script _REQUIRE= LOGIN Index: net-p2p/rtorrent/Makefile =================================================================== --- net-p2p/rtorrent/Makefile (revision 303040) +++ net-p2p/rtorrent/Makefile (working copy) @@ -37,6 +37,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not configure on arm +.endif + .if !defined(WITHOUT_XMLRPC) CONFIGURE_ARGS+= --with-xmlrpc-c LIB_DEPENDS+= xmlrpc.3:${PORTSDIR}/net/xmlrpc-c-devel Index: net/socat/Makefile =================================================================== --- net/socat/Makefile (revision 303041) +++ net/socat/Makefile (working copy) @@ -43,4 +43,10 @@ cd ${WRKSRC} && ${INSTALL_DATA} ${PORTDOCS} ${DOCSDIR} .endif -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not configure on arm +.endif + +.include Index: net/vnc/Makefile =================================================================== --- net/vnc/Makefile (revision 303041) +++ net/vnc/Makefile (working copy) @@ -44,6 +44,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + .if !defined(WITHOUT_SERVER) MASTER_SITES+= ${MASTER_SITE_XORG:S/$/:x/} MASTER_SITE_SUBDIR+= 4.3.0/:x Index: sysutils/lsof/Makefile =================================================================== --- sysutils/lsof/Makefile (revision 303041) +++ sysutils/lsof/Makefile (working copy) @@ -44,6 +44,10 @@ .include +.if ${ARCH} == "arm" +BROKEN= Does not compile on arm +.endif + CONFIGURE_SCRIPT= Configure CONFIGURE_ARGS= -n freebsd CONFIGURE_ENV= LSOF_CC="${CC}" FREEBSD_SYS="${SRC_BASE}/sys" Index: www/varnish/Makefile =================================================================== --- www/varnish/Makefile (revision 303041) +++ www/varnish/Makefile (working copy) @@ -55,4 +55,10 @@ .endfor @${CAT} ${PKGMESSAGE} -.include +.include + +.if ${ARCH} == "arm" +BROKEN= Does not configure on arm +.endif + +.include >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-ports-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports-bugs To unsubscribe, send any mail to "freebsd-ports-bugs-unsubscribe@freebsd.org" ----- End forwarded message ----- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:26:26 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A8771065672 for ; Thu, 23 Aug 2012 23:26:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 129F68FC14 for ; Thu, 23 Aug 2012 23:26:25 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2404541pbb.13 for ; Thu, 23 Aug 2012 16:26:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=huWGlQ/K+J9q23N2Dy+i8d3okVdSWb7iIk3+N02V218=; b=Ai2SSPFQDRzG8+NiO8AOnhKYVRjEpwsfXJ44j/Jkx8aOdkozMvxTaDQusMZP3vMwug 363VEOhvOvtKreieuCGw7d3tPPZew/zO0pcG8zZM1R9Zrf9iDxmYaEFSPNCc2VCjBu3P Rn5o7UiL3CpV3v8Qthbr40mk7YhyGTe4LKTm+PFLA5p+jqeGIGiLq+FWsOc9/QOCYzbh 4EbyiHJLUuJAvquQ5s5WK4G4HQJYpW+OIyOiID54mBTwgKC5XnJ0Ft8hHffIMutn5eU0 Bkg0yIT9x4Y+UyGBA5uBGehydpSBhYMq/1ctITMFL3ystI4WSRK8V1f8/KpjjrBUFIoM oYUQ== Received: by 10.68.196.193 with SMTP id io1mr8509341pbc.17.1345764385480; Thu, 23 Aug 2012 16:26:25 -0700 (PDT) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id pj10sm6923195pbb.46.2012.08.23.16.26.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 16:26:25 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345763393.27688.578.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 17:26:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQmDmyZ8ZnGxKySA+cpI9khCWpOI3QVoLO8bdUAxJVXAUyYTqz1TvLugHWzV6tsbvIUDolGz Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:26:26 -0000 On Aug 23, 2012, at 5:09 PM, Ian Lepore wrote: > On Thu, 2012-08-23 at 15:50 -0600, Warner Losh wrote:=20 >> On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: >>> A recent innocuous change to the USB driver code caused intermittant >>> errors in the umass(4) driver on ARM and MIPS platforms, and this >>=20 >> I think the proper solution is to segregate DMA and non-DMA parts of = structures so that you don't have both sharing a cache line. >>=20 >> I also wonder why we don't allocate the DMA memory for these = structures separately from the non-DMA parts. This would eliminate the = USB_CACHE_BYTES kludge (which is CPU dependent, not arch dependent) and = move the knowledge of this junk into busdma layer where it belongs. = =46rom my understanding of the issue, this would completely eliminate = the problem forever! >>=20 >> Sharing a cacheline between something that is DMA aware and something = that is just begging for trouble. We're doing more work than we need = to to support this dubious feature and we'd be miles ahead if we could = not share at all. >>=20 >> Warner >>=20 >=20 > It seems to me that what we have here is a new type of constraint on = DMA > operations, and we need a way to communicate that constraint from the > part of the platform support code that knows about it to the drivers = and > driver support code that needs to know. The way we communicate DMA > constraints is with a busdma tag, but right now that tag only > communicates constraints that were needed for ISA and PCI busses, = namely > buffer alignment, boundary-crossing restrictions, and exclusion > regions. =20 >=20 > Now we have a new type of constraint, I think of it as "granularity". > In effect, we have a DMA system that can only do DMA in cacheline = sized > chunks. Even when the IO size -- and thus the number of "bits on the > wire" -- is less than the cacheline size, at the end of the DMA > operation (which includes the software-assisted coherency operations) > the number of bytes in memory that may be modified is the size of a > cacheline. This is because "the DMA system" is not just the engine = that > moves bytes around, it's the combination of hardware and software that > work together to maintain cache coherency. But this isn't new. It is an alignment requirement, which carries with = it an implicit size requirement. If you enforce the alignment, and = force all 'sub buffers' to have this alignment, you don't need the new = thing. > Ideally we'd find a way to communicate this new constraint using the > existing mechanism, the busdma tag, and ideally we'd not have to = change > every existing call to bus_dma_tag_create() to add a new parm. As I > understand it, parent tags are now passed down through the newbus > hierarchy consistantly, such that a tag at the nexus level could > describe a platform requirement such as granularity, and all devices = and > the helper code they use will have access to that constraint via > inheritance from ancestors' tags. Maybe we could have a new flavor of > bus_dma_tag_create() that takes a struct of parms, and existing calls > wouldn't have to be changed. Wouldn't a simpler solution be to just make this alignment requirement = be part of the global parent tag on these platforms and to make sure all = drivers on those platforms use it and don't cop-out and pass NULL? > Communicating the constraint is only part of the problem; it also has = to > be easy for drivers to work with that constraint, especially drivers > that are not targeted specifically at platforms with granular DMA. I > think we can achieve a huge chunk of that purely within the arm/mips > implementation of bus_dmamem_alloc(), but even so there would be a new > conceptual limitation on using that routine: it is specifically for > allocating DMA buffers, and that means that there will be a new a rule > that the CPU cannot access any memory within that buffer while an IO > operation is in progress. I don't think we should pander to drivers that don't know how to do DMA = properly. We get it almost right in bus_dma now. However, going from = almost right to completely right is hard and we keep uncovering edge = cases that bite us. Wouldn't it be better to eliminate all these weird = edge cases? > I'd also like to say there's a new rule that you cannot subdivide a > buffer obtained from bus_dmamem_alloc() into multiple buffers, or into = a > combination of DMA and CPU-accessed data. That would be bad news for > the USB subsystem, and perhaps other drivers. If this idea is either > impossible or particularly contentious, then I guess we'd need some = new > helper routines so that a driver can subdivide the memory in a way = that > doesn't violate any constraints implied by the tag used to allocate = the > buffer. When the USB subsystem went into the tree, this was one of the = criticisms that was ignored. It has come back to bite us time and time = again. Perhaps it is time to fix it once and for all. > Not all IO occurs using buffers obtained from bus_dmamem_alloc(), and = I > doubt we can reasonably ever require that it be so. =20 True, but the I/O that's not in memory from bus_dmamem_alloc is page = aligned. > I think the only > hope we have of handling that problem is to bounce the requests that > don't meet the granularity constraint, just as we'd have to do if the > caller-supplied buffer fell into an exclusion zone or violated an > alignment or boundary constraint. When I've tossed this idea out in = the > past there was instant resistance. Yeah, bounce buffers are massively > inefficient, but my experience has been that most of the IO that isn't > aligned and sized to a multiple of a cacheline is small IO (a few to a > few dozen bytes). I've never seen a case of page-sized or larger IO > requests that required partial-cacheline handling. I'm sure some > examples exist, but they're probably more the exception than the rule. > (And the bad performance you'd get from bouncing and copying massive > bulk data flow would be a powerful incentive to track down the culprit > and improve the driver.) That's also the underlying idea in the bus_dma stuff. You give the = constraints, you get the buffers and if you have a buffer that's outside = the constraints it gets bounced. That's why the sync operations on on = DMA items, not on cache line items. While cache lines are one issue, = memory placement can be another. Floppy drives, for example, couldn't = DMA past the first 16MB and if you have a buffer passed in that's = outside of that, it bounces. If this bouncing produces slower code, = then the drivers should be updated to have better alignment. The USB subsystem is making assumptions about the underlying cache = mechanisms that aren't really true. Ideally, we could get it to stop = doing that. Warner= From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:27:12 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B824106564A for ; Thu, 23 Aug 2012 23:27:12 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id EE3B28FC18 for ; Thu, 23 Aug 2012 23:27:11 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta05.emeryville.ca.mail.comcast.net with comcast id qNv21j0041afHeLA5PTBs3; Thu, 23 Aug 2012 23:27:11 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id qPTA1j00D4NgCEG8dPTAp2; Thu, 23 Aug 2012 23:27:11 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NNR8Lw025556; Thu, 23 Aug 2012 17:27:08 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 17:27:08 -0600 Message-ID: <1345764428.27688.591.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:27:12 -0000 On Thu, 2012-08-23 at 16:09 -0700, Adrian Chadd wrote: > [snip] > > Whoa, there's USB code that has these small buffers straddle cache lines? > > Why aren't they just allocated to always be in their own separate > buffers, so they don't ever have to worry about overlapping cache > lines? Yes, but note that with our current code, a small buffer doesn't have to straddle a cacheline boundary to invoke the partial cacheline flush logic. Its very smallness does so -- if a buffer doesn't start on a cacheline boundary, and/or if its size doesn't exactly equal a multiple of the cacheline size, then it's a partial cacheline flush situation. So even a driver striving to work around this trouble can get into trouble -- it uses bus_dmamem_alloc() to grab a buffer for a 13 byte status message. It gets a 16-byte chunk from the kernel allocator, and the other 16 bytes of that cacheline are given to something else in the kernel, and now you have DMA and CPU access going on in the same cacheline despite your efforts to Do The Right Thing with buffer allocation. (At work we avoid this by setting the kernel minimum allocation size to 32 bytes instead of 16. We did so after being burned by exactly this situation -- the "other 16 bytes" in our case belonged to a struct ithread, and trying to track down a lockup that was caused by a partial cacheline flush corrupting the struct ithread kept me entertained for a couple weeks.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:36:46 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5376E106564A; Thu, 23 Aug 2012 23:36:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 17DD18FC15; Thu, 23 Aug 2012 23:36:45 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2415467pbb.13 for ; Thu, 23 Aug 2012 16:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ZqDIjzxMgU3yZwSHpcg2vnW8k3VCuuGcmucl0nHa5xc=; b=qFD3SNi7TjXoHyZyjZc9Cgz9jPt4O0ldrMYgS8HZgp7xzg9tLQju4GahEViI36qO7G 69jHiCDwYe7Unv2VK5NwuH8/LSHXHoH7+cQYP30Oq/Dy7aUEd5k07rptR1hfkbTbXXsp dp5tVjalA9IKe87/jGIPFa4op6MpTriSAw93In2RDvlV5a29SSzxJ6NEXxz+EQB8QQhH CEh2GWHctCICw98iocvHxn0xjQYiRupsd1hVXuKZ9a+V5dEZfUjGGhdinEC+OjmH9Idi 2x3D/BEge6egfP/6T8/ziCRcpdiu7a2IpNOFwMVrzTq6XF7gcz/OQ/p9M2YZvfAbgbSZ qSPA== MIME-Version: 1.0 Received: by 10.68.136.40 with SMTP id px8mr8215347pbb.153.1345765005641; Thu, 23 Aug 2012 16:36:45 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 16:36:45 -0700 (PDT) In-Reply-To: <1345764428.27688.591.camel@revolution.hippie.lan> References: <1345757300.27688.535.camel@revolution.hippie.lan> <1345764428.27688.591.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 16:36:45 -0700 X-Google-Sender-Auth: 8N9-uFx59Shvyoz92HPvSALf2iE Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:36:46 -0000 Right, that's what Linux does for ARM/MIPS. It just sets the minimum allocation size to be cache line sized. That way they didn't have to fix their USB and network stack code. .. or, we could fix the USB stack code by saying that anything being used as a DMA buffer needs to be minimum cache line size (which can be determined at run time if appropriate) and make the minimum allocation that. Then either it uses a separate allocation for each buffer or it allocates one big set of buffers and chops them up in at least "cache line size" bits. That reminds me, I should do that to the descriptor allocation in the Atheros driver - ie, round up the descriptor allocation size to a multiple of a cache line. That way DMAs don't conflict with the next DMAed buffer.. Adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:46:14 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6E131065676 for ; Thu, 23 Aug 2012 23:46:14 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 84C368FC0A for ; Thu, 23 Aug 2012 23:46:14 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta11.emeryville.ca.mail.comcast.net with comcast id qNrM1j0031bwxycABPl747; Thu, 23 Aug 2012 23:45:07 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta18.emeryville.ca.mail.comcast.net with comcast id qPl61j00R4NgCEG8ePl6lZ; Thu, 23 Aug 2012 23:45:07 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NNj4Mr025577; Thu, 23 Aug 2012 17:45:04 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Warner Losh In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 17:45:03 -0600 Message-ID: <1345765503.27688.602.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:46:14 -0000 On Thu, 2012-08-23 at 17:26 -0600, Warner Losh wrote: > > On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: > > Now we have a new type of constraint, I think of it as "granularity". > > In effect, we have a DMA system that can only do DMA in cacheline sized > > chunks. Even when the IO size -- and thus the number of "bits on the > > wire" -- is less than the cacheline size, at the end of the DMA > > operation (which includes the software-assisted coherency operations) > > the number of bytes in memory that may be modified is the size of a > > cacheline. This is because "the DMA system" is not just the engine that > > moves bytes around, it's the combination of hardware and software that > > work together to maintain cache coherency. > But this isn't new. It is an alignment requirement, which carries > with it an implicit size requirement. If you enforce the alignment, > and force all 'sub buffers' to have this alignment, you don't need the > new thing. So do you think it's safe to assume that any given dma tag that has an alignment constraint also implicitly has a buffer size constraint that the size must be a multiple of the alignment? What if we have a platform with a 32-byte cacheline / DMA granularity, and then we have a builtin device on that SoC which can only do DMA on a 64K alignment (which its tag would reflect), but the hardware can move as little as 1 byte at a time? Children of that bridge device come along and allocate little 16-byte buffers that eat 16 pages each. It doesn't seem all that far-fetched to me. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:48:51 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D75106564A; Thu, 23 Aug 2012 23:48:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 39D918FC17; Thu, 23 Aug 2012 23:48:50 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2428732pbb.13 for ; Thu, 23 Aug 2012 16:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Mskt1FyQ/HqkFMIEUCOxaM1D7q7pn1393qcB/jAWPnU=; b=Cog3Xq8zSN5Zl7K2a0nXw/INEb20LCEzMNo7+vVAij2/aBmAPh+3U/OeBe74m0dmGu yAdtXDFPqSEqFCe8mcV593Etog3zCrMHGhF47i0iRyX9oV1gNY2rd0uKCrujMR0lghrE xoLWOYXbxIsljKOc7nRsv7VN8fykkPqlryniKOtsuUZIOnQlNS90mNOdbLPIm/EuaavE AhpgCjau9GHafS+R1SB4v3+8ZVMYaMvawTyITBPJqGICI01PtxMnkSh2codWZU5+ffbF RfElqIHdkf2EoS0iy0+zJi5plfdvMjcWRuhux+m1H+QFy7lNg/SAFMIFedzmPkv8L79C IqOw== MIME-Version: 1.0 Received: by 10.68.231.233 with SMTP id tj9mr8442260pbc.39.1345765730704; Thu, 23 Aug 2012 16:48:50 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 16:48:50 -0700 (PDT) In-Reply-To: <1345765503.27688.602.camel@revolution.hippie.lan> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 16:48:50 -0700 X-Google-Sender-Auth: xNYhy3PgvZjcI4uwRsLgaOc5SX4 Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:48:51 -0000 On 23 August 2012 16:45, Ian Lepore wrote: > So do you think it's safe to assume that any given dma tag that has an > alignment constraint also implicitly has a buffer size constraint that > the size must be a multiple of the alignment? > > What if we have a platform with a 32-byte cacheline / DMA granularity, > and then we have a builtin device on that SoC which can only do DMA on a > 64K alignment (which its tag would reflect), but the hardware can move > as little as 1 byte at a time? Children of that bridge device come > along and allocate little 16-byte buffers that eat 16 pages each. It > doesn't seem all that far-fetched to me. That hardware would suck, wouldn't it? In what case though would the hardware say it can only DMA on a 64k alignment BUT move one byte at a time? Then what would the starting address be for each DMA? adrian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:51:13 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A646F1065670; Thu, 23 Aug 2012 23:51:13 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 213518FC0C; Thu, 23 Aug 2012 23:51:12 +0000 (UTC) Received: by vcbgb22 with SMTP id gb22so1903080vcb.13 for ; Thu, 23 Aug 2012 16:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; bh=JWgh66ZmryhJI/TjUNJMyoMIjSInrwXjCxbw7sDO0VU=; b=PZ8SFjrKUcp9xmS4PNcgWu/uw++fdJfnc3+SvKpzXkSwwVr50wSmz1+tRNT8abbGCF pD7n+mrr2bczBzMck/r5HVeaw2iQ8PY7TsewLVaT9uCez0hpNTwRfgygw5lg2u021j8e tKVDRgLq5mT+G83tr6qqkuMhr/6vUHFB7u1J/UHCAzT9x0KG2xC0FQ6e8xQ4VFs1Csuu hOPedDLB1aqUk7V2gTZKwnf3EQBYy9AxHZAs74HzGQGvCAC1bTyCcC+mGobafrZ7nopb Bxn2nF3M/SvOpaARk+DrRgAK1iSBsAo0uDWyhvn85Jthb90lOKSMv8An6LsuB4wpCerT c5DA== Received: by 10.220.247.137 with SMTP id mc9mr2858779vcb.52.1345765872283; Thu, 23 Aug 2012 16:51:12 -0700 (PDT) Received: from kan.dyndns.org (c-24-63-226-98.hsd1.ma.comcast.net. [24.63.226.98]) by mx.google.com with ESMTPS id s1sm4496996vdi.14.2012.08.23.16.51.10 (version=SSLv3 cipher=OTHER); Thu, 23 Aug 2012 16:51:11 -0700 (PDT) Date: Thu, 23 Aug 2012 19:51:02 -0400 From: Alexander Kabaev To: Warner Losh Message-ID: <20120823195102.2dcc1fcc@kan.dyndns.org> In-Reply-To: <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/xAKsUfCFhIS7lv_PazDak7K"; protocol="application/pgp-signature" Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:51:13 -0000 --Sig_/xAKsUfCFhIS7lv_PazDak7K Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 23 Aug 2012 15:50:35 -0600 Warner Losh wrote: >=20 > On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: > > A recent innocuous change to the USB driver code caused intermittant > > errors in the umass(4) driver on ARM and MIPS platforms, and this >=20 > I think the proper solution is to segregate DMA and non-DMA parts of > structures so that you don't have both sharing a cache line. >=20 > I also wonder why we don't allocate the DMA memory for these > structures separately from the non-DMA parts. This would eliminate > the USB_CACHE_BYTES kludge (which is CPU dependent, not arch > dependent) and move the knowledge of this junk into busdma layer > where it belongs. From my understanding of the issue, this would > completely eliminate the problem forever! >=20 > Sharing a cacheline between something that is DMA aware and something > that is just begging for trouble. We're doing more work than we > need to to support this dubious feature and we'd be miles ahead if we > could not share at all. >=20 > Warner I agree with Warner that this should be addressed at busdma level. When asked for DMA buffer, it should contrain its start address size to the cache line boundary. USB is insane allocating DMA buffers inside of own transfer structure and that was stated on a more than one occasion already. Since USB code refused to budge, we came with a horrible USB_CACHE_BYTES hack as as _temporary_ workaround. --=20 Alexander Kabaev --Sig_/xAKsUfCFhIS7lv_PazDak7K Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iD8DBQFQNsHtQ6z1jMm+XZYRAqeaAJsE2dyZ0FISrcOVX3Je3YvLQ1MNZQCfcF+M bBDN5eQWXQgUWXM3/UOthNI= =mcBu -----END PGP SIGNATURE----- --Sig_/xAKsUfCFhIS7lv_PazDak7K-- From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:55:12 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5EC8106566B for ; Thu, 23 Aug 2012 23:55:12 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id 79C4C8FC15 for ; Thu, 23 Aug 2012 23:55:12 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta12.emeryville.ca.mail.comcast.net with comcast id qCza1j0051vN32cACPvCZv; Thu, 23 Aug 2012 23:55:12 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta22.emeryville.ca.mail.comcast.net with comcast id qPvA1j00d4NgCEG8iPvBTY; Thu, 23 Aug 2012 23:55:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7NNt9ti025603; Thu, 23 Aug 2012 17:55:09 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 17:55:09 -0600 Message-ID: <1345766109.27688.606.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:55:12 -0000 On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote: > On 23 August 2012 16:45, Ian Lepore wrote: > > > So do you think it's safe to assume that any given dma tag that has an > > alignment constraint also implicitly has a buffer size constraint that > > the size must be a multiple of the alignment? > > > > What if we have a platform with a 32-byte cacheline / DMA granularity, > > and then we have a builtin device on that SoC which can only do DMA on a > > 64K alignment (which its tag would reflect), but the hardware can move > > as little as 1 byte at a time? Children of that bridge device come > > along and allocate little 16-byte buffers that eat 16 pages each. It > > doesn't seem all that far-fetched to me. > > That hardware would suck, wouldn't it? > > In what case though would the hardware say it can only DMA on a 64k > alignment BUT move one byte at a time? Then what would the starting > address be for each DMA? > Maybe the device has a reduced number of address bits in its registers and the low-order bits always start at zero and increment internally in a wider register so that any length dma can happen, but it has to start on a 64k boundary. Maybe the address you pass it has to be a 64k boundary, but then the bytes actually end up in one-of-N slots within that 64k region, based on other parameters of the transfer. I've worked with some strange hardware over the years. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Aug 23 23:59:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 458DC106566B; Thu, 23 Aug 2012 23:59:17 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0784E8FC15; Thu, 23 Aug 2012 23:59:16 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so2439273pbb.13 for ; Thu, 23 Aug 2012 16:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bVpnJB73bCLefXPcIvjYhYqKlLLMR3NxqYPJzQo36bs=; b=l37Rd9vmQ/ynZvNsTSwDhK9YQVWXfbu3PrJPR6iGT/dxcAkV0v74ykjudVMxy4x9aM WQy/q8uvDFSJNXPiXtsWxCMW+oMzZoHCj+QDu153Vlr7uZs96ZrrcvurLW2Zk8jmM0Qg ynnQeJ3vNToaY8rJOte5Khe+34yMmsXk1j6N1v/1jHpK2TTD4ogFT6O81cvcKkc1J43y EFdZZjIxsDmwwXp+MgBY9UTRqFgcu16kkPXb/S01nH+a7NQqIOkS9cCsOoMTHgcyWuGe Z1ZdsSqGNOEmFWiFaxgY2u8yhwhV7czSYeJiA7uHYMWB8I0evjvDowD0FOmtmkCOrzwe oXyw== MIME-Version: 1.0 Received: by 10.68.138.169 with SMTP id qr9mr8493185pbb.27.1345766356862; Thu, 23 Aug 2012 16:59:16 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.68.36.106 with HTTP; Thu, 23 Aug 2012 16:59:16 -0700 (PDT) In-Reply-To: <1345766109.27688.606.camel@revolution.hippie.lan> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> <1345766109.27688.606.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 16:59:16 -0700 X-Google-Sender-Auth: lfQnLTGTsXKt1gXoEwgg8ou0Azs Message-ID: From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 23:59:17 -0000 On 23 August 2012 16:55, Ian Lepore wrote: >> In what case though would the hardware say it can only DMA on a 64k >> alignment BUT move one byte at a time? Then what would the starting >> address be for each DMA? >> > > Maybe the device has a reduced number of address bits in its registers > and the low-order bits always start at zero and increment internally in > a wider register so that any length dma can happen, but it has to start > on a 64k boundary. > > Maybe the address you pass it has to be a 64k boundary, but then the > bytes actually end up in one-of-N slots within that 64k region, based on > other parameters of the transfer. > > I've worked with some strange hardware over the years. Right. That's pretty odd though. But now I understand where you're coming from. I still think the short term solution should be "fix the USB stack to not do that!" The longer term problem is likely to figure out what makes sense. Eg, if you're going to allow the allocator to interleave 16 byte chunks (on a 32 byte cache line platform) with some being DMA buffers and others being non-DMA buffers; or whether you enforce that the whole chunk is a DMA buffer for your hardware and you look after it, or something else.. Adrian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 24 00:51:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A69771065675 for ; Fri, 24 Aug 2012 00:51:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8210C8FC1B for ; Fri, 24 Aug 2012 00:51:31 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta01.emeryville.ca.mail.comcast.net with comcast id qEbr1j00B0FhH24A1QrXVy; Fri, 24 Aug 2012 00:51:31 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta08.emeryville.ca.mail.comcast.net with comcast id qQrV1j00l4NgCEG8UQrWx7; Fri, 24 Aug 2012 00:51:30 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7O0pSKT025681; Thu, 23 Aug 2012 18:51:28 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Adrian Chadd In-Reply-To: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 23 Aug 2012 18:51:28 -0600 Message-ID: <1345769488.27688.625.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:51:31 -0000 On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote: > On 23 August 2012 16:45, Ian Lepore wrote: > > > So do you think it's safe to assume that any given dma tag that has an > > alignment constraint also implicitly has a buffer size constraint that > > the size must be a multiple of the alignment? > > > > What if we have a platform with a 32-byte cacheline / DMA granularity, > > and then we have a builtin device on that SoC which can only do DMA on a > > 64K alignment (which its tag would reflect), but the hardware can move > > as little as 1 byte at a time? Children of that bridge device come > > along and allocate little 16-byte buffers that eat 16 pages each. It > > doesn't seem all that far-fetched to me. > > That hardware would suck, wouldn't it? > Thinking about this some more, I think that at least for now we don't have to communicate a new constraint to bus_dma_tag_create(), nor do we need to assume that a size constraint is the same as an alignment constraint. The size constraint is machine dependant in nature, and the busdma implementation code is also MD, and thus should have some MD way of knowing about this constraint for itself without being told by callers. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Aug 24 03:56:25 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4875B1065670 for ; Fri, 24 Aug 2012 03:56:25 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 035F78FC0C for ; Fri, 24 Aug 2012 03:56:24 +0000 (UTC) Received: by ialo14 with SMTP id o14so3229654ial.13 for ; Thu, 23 Aug 2012 20:56:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=A8ZRIPSNaFjBDKLw6gxuyEvrrxkJ3KqudBpGidIaZTY=; b=bf6TtGZ8aHYh4gBCeiSrQRW5nDWc+svFUd+CJ6/CYhoQFb3LbCsdQ66Xq1WoZPhGf5 /AqG6gwEwCxHi3b+9l2AbnneZUx0afGAw1TSgVADwQAUyuUUs+3GGBIio+6MmGraZZJ+ gNE1NOVgvWqavcyd3yecGJsV8OV/zDV9WVlUlhnmrmIm1k0IFLTnqYPSseNVMbl/MK9L MiUf/T6UPb/k+NevvQbkf/Qpe35LSaEMGvox4XDV43fWFTF+DZsp4jvB2qtQKwh0bKab 6pVNdeu4Gwwp5AvULJoVNcb7Dc3JnMg1cB52uJYlCB3yEhQ5oOTnsRHztZXusJ2g7x1w VCQA== Received: by 10.50.34.131 with SMTP id z3mr649492igi.45.1345780584053; Thu, 23 Aug 2012 20:56:24 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id va9sm1181375igb.17.2012.08.23.20.56.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 20:56:22 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345765503.27688.602.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 21:56:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlnayACXKWa3cNLCafFwLzqSWAwj6AreXV6sttD3YnBX5vj+GoumdWkC1cxbkGDOjU/j8Xu Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 03:56:25 -0000 On Aug 23, 2012, at 5:45 PM, Ian Lepore wrote: > On Thu, 2012-08-23 at 17:26 -0600, Warner Losh wrote: >>> On Aug 23, 2012, at 3:28 PM, Ian Lepore wrote: >>> Now we have a new type of constraint, I think of it as = "granularity". >>> In effect, we have a DMA system that can only do DMA in cacheline = sized >>> chunks. Even when the IO size -- and thus the number of "bits on = the >>> wire" -- is less than the cacheline size, at the end of the DMA >>> operation (which includes the software-assisted coherency = operations) >>> the number of bytes in memory that may be modified is the size of a >>> cacheline. This is because "the DMA system" is not just the engine = that >>> moves bytes around, it's the combination of hardware and software = that >>> work together to maintain cache coherency. >> But this isn't new. It is an alignment requirement, which carries >> with it an implicit size requirement. If you enforce the alignment, >> and force all 'sub buffers' to have this alignment, you don't need = the >> new thing.=20 >=20 > So do you think it's safe to assume that any given dma tag that has an > alignment constraint also implicitly has a buffer size constraint that > the size must be a multiple of the alignment? Yes. If something must be aligned to N bits, chances are it doesn't = decode the lower N bits which implies a size constraint. > What if we have a platform with a 32-byte cacheline / DMA granularity, > and then we have a builtin device on that SoC which can only do DMA on = a > 64K alignment (which its tag would reflect), but the hardware can move > as little as 1 byte at a time? Children of that bridge device come > along and allocate little 16-byte buffers that eat 16 pages each. It > doesn't seem all that far-fetched to me. This would be a very odd hardware. DMA aligned to 64k that can only = move one byte seems far fetched. How useful would such a design be? = How would you do scatter gather on such a design? But this isn't what I'm saying. If the cache line size is 32, then for = DMA we only ever give out chunks of 32 or larger. In that case, the = split cache line situation you gave as an example can't happen.= From owner-freebsd-arm@FreeBSD.ORG Fri Aug 24 04:00:48 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF308106564A for ; Fri, 24 Aug 2012 04:00:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 640FD8FC08 for ; Fri, 24 Aug 2012 04:00:47 +0000 (UTC) Received: by ialo14 with SMTP id o14so3236391ial.13 for ; Thu, 23 Aug 2012 21:00:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/fumm9ehnwMxdlhILXylmJSdzHQbk9R61mCz3E6uRRA=; b=Y1nANzas7VseT3tvr6+TY5dSVO9x51/3B5TPla+iBPeM1wWV+ca3bO7Oy8cBQsYANJ 9tLmlwdx/V6KqJFEWgR8zb5ObQIAY43EWIBi6iKrGQIVI5qBbUVC28VZjXIsZap+kC9z q2E5Pz56CeElbAo0MfWAoenjnchRDkdocRndm5OZd/FqN7meJcnarJRH2zsiP6D3wnMp A49GUj849baNbpd+hj2vCHMQ+66GqTPG5650Dynzwmn16VPPCyRgwaqDztDAT6P1bzUg cj5cmpzubkCd8/bHJEBkmznZ3j9J5iI6TI+UYfWAlxdoTgny8EfBIJpijnTMUW+H78xD Y93g== Received: by 10.50.47.161 with SMTP id e1mr702151ign.11.1345780846750; Thu, 23 Aug 2012 21:00:46 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ua2sm3449366igb.7.2012.08.23.21.00.45 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 21:00:46 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 23 Aug 2012 22:00:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> <1345766109.27688.606.camel@revolution.hippie.lan> To: Adrian Chadd X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQkkyLWgwLMvDQO8faIw4iDVeOw5RhXSkqqgVZjv1SsqdlUs2C/514zcV3AgbM9cCG6T8J13 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 04:00:48 -0000 On Aug 23, 2012, at 5:59 PM, Adrian Chadd wrote: > On 23 August 2012 16:55, Ian Lepore = wrote: >=20 >>> In what case though would the hardware say it can only DMA on a 64k >>> alignment BUT move one byte at a time? Then what would the starting >>> address be for each DMA? >>>=20 >>=20 >> Maybe the device has a reduced number of address bits in its = registers >> and the low-order bits always start at zero and increment internally = in >> a wider register so that any length dma can happen, but it has to = start >> on a 64k boundary. >>=20 >> Maybe the address you pass it has to be a 64k boundary, but then the >> bytes actually end up in one-of-N slots within that 64k region, based = on >> other parameters of the transfer. >>=20 >> I've worked with some strange hardware over the years. >=20 > Right. That's pretty odd though. But now I understand where you're = coming from. >=20 > I still think the short term solution should be "fix the USB stack to > not do that!" >=20 > The longer term problem is likely to figure out what makes sense. Eg, > if you're going to allow the allocator to interleave 16 byte chunks > (on a 32 byte cache line platform) with some being DMA buffers and > others being non-DMA buffers; or whether you enforce that the whole > chunk is a DMA buffer for your hardware and you look after it, or > something else.. The bottom line is that you can't mix things like that when cache lines = are involved. The current code that tries is doomed to failure. Doomed. = You just can't control all flushes, as Ian's missive demonstrates, and = trying to accommodate code that does this I don't think can possibly = work. All the interrupt masking, copying in and out, etc I fear is = doomed to utter and abject failure. =20 Warner= From owner-freebsd-arm@FreeBSD.ORG Fri Aug 24 04:03:23 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF8551065670 for ; Fri, 24 Aug 2012 04:03:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 869DD8FC0C for ; Fri, 24 Aug 2012 04:03:23 +0000 (UTC) Received: by ialo14 with SMTP id o14so3240748ial.13 for ; Thu, 23 Aug 2012 21:03:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=eI5+aVAQMNRlLMXxkUR0Gm4Y8aCwg0o1YoPQvX3yxX8=; b=Cfb4pbWg3vlU4NEutQ2EnkUztDTX6SC+Jm7GEuQk3je+MDmujRAZ9+s222KOJExBIX QxhUVFsNlfXlrP+yrlqWM6ctW/TtmBoiWlIn8/2lyhFOi5g3Im7cHvZozYeSs6ZWaQTK J/XGJTbWY6caIZ+UrNdHJFvraftTdORwhD+aGdNgrhx20C5R8s8thAArFd/gOj1Y2QwU dbwhiOkJOahZk3JqOxL6a4omDutsG2k11Kd2jCi4owV2WX7D7RFvN2LWN1yso8OLgNMC GOpV6KMGH3T3kLpaKFQTwc69LvQ37/0jOlQLJhzOZ7AHiydxuWIUIvAf7ee6ueMjsXkX b82g== Received: by 10.50.213.106 with SMTP id nr10mr617077igc.58.1345781002439; Thu, 23 Aug 2012 21:03:22 -0700 (PDT) Received: from 63.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ey10sm3397801igb.17.2012.08.23.21.03.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Aug 2012 21:03:21 -0700 (PDT) Sender: Warner Losh Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1345769488.27688.625.camel@revolution.hippie.lan> Date: Thu, 23 Aug 2012 22:03:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6639450F-11BB-4D01-8D0C-CD66B427EF08@bsdimp.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <1345765503.27688.602.camel@revolution.hippie.lan> <1345769488.27688.625.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQlqDGjfTBCPWpAwCTqI2FpK5DGgFeGh2ek+pdMCDCDxkzLRC3ExNSUj0KP7qxg0QynZ3jv6 Cc: freebsd-arm@freebsd.org, freebsd-mips@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Partial cacheline flush problems on ARM and MIPS X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 04:03:24 -0000 On Aug 23, 2012, at 6:51 PM, Ian Lepore wrote: > On Thu, 2012-08-23 at 16:48 -0700, Adrian Chadd wrote: >> On 23 August 2012 16:45, Ian Lepore = wrote: >>=20 >>> So do you think it's safe to assume that any given dma tag that has = an >>> alignment constraint also implicitly has a buffer size constraint = that >>> the size must be a multiple of the alignment? >>>=20 >>> What if we have a platform with a 32-byte cacheline / DMA = granularity, >>> and then we have a builtin device on that SoC which can only do DMA = on a >>> 64K alignment (which its tag would reflect), but the hardware can = move >>> as little as 1 byte at a time? Children of that bridge device come >>> along and allocate little 16-byte buffers that eat 16 pages each. = It >>> doesn't seem all that far-fetched to me. >>=20 >> That hardware would suck, wouldn't it? >>=20 >=20 > Thinking about this some more, I think that at least for now we don't > have to communicate a new constraint to bus_dma_tag_create(), nor do = we > need to assume that a size constraint is the same as an alignment > constraint. The size constraint is machine dependant in nature, and = the > busdma implementation code is also MD, and thus should have some MD = way > of knowing about this constraint for itself without being told by > callers. And also allow for different cache line sizes for different CPUs within = the same MACHINE/MACHINE_ARCH, which is common in MIPS land, at least. Warner