From owner-freebsd-embedded@FreeBSD.ORG Wed Nov 30 19:44:02 2011 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 086441065672 for ; Wed, 30 Nov 2011 19:44:02 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2001:470:1f0b:105e::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id C1D378FC12 for ; Wed, 30 Nov 2011 19:44:01 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 4BF3F1131A5 for ; Wed, 30 Nov 2011 20:44:00 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Stefan Bethke In-Reply-To: <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> Date: Wed, 30 Nov 2011 20:43:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C0E9CA3-E130-4E9A-ABCC-1782E28999D1@lassitu.de> References: <68ABED76-CB1F-405A-8036-EC254F7511FA@lassitu.de> <3B3DB17D-BF87-40EE-B1C1-445F178E8844@lassitu.de> <86030CEE-6839-4B96-ACDC-2BA9AC1E4AE4@lassitu.de> <2D625CC9-A0E3-47AA-A504-CE8FB2F90245@lassitu.de> <203BF1C8-D528-40C9-8611-9C7AC7E43BAB@lassitu.de> To: freebsd-embedded@freebsd.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: TL-WR1043: switch X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 19:44:02 -0000 One step closer: http://www.lassitu.de/freebsd/rtl8366ctl.tbz The starting point for a configuration utility. I've implemented two = "drivers": direct bitbanging access via gpio(4), or I2C access via = iic(4). The I2C framework makes a faulty assumption that the read/not-write bit = of the first byte (the address) indicates whether reads or writes are to = follow. While many simple I2C devices usually will follow this rule, = it's not prescribed by the protocol (AFAICT), and is incompatible with = the way the RTL8366 familiy uses the bus: after sending the = address+read/not-write byte, two register address bytes are sent, then = the 16-bit register value is sent or received. While the register write = access can be performed as a 4-byte write, the read access requires the = read bit to be set, but the first two bytes for the register address = then need to be transmitted. This patch removes the faulty check: Index: sys/dev/iicbus/iiconf.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/iicbus/iiconf.c (revision 228073) +++ sys/dev/iicbus/iiconf.c (working copy) @@ -244,7 +244,7 @@ struct iicbus_softc *sc =3D (struct iicbus_softc = *)device_get_softc(bus); =09 /* a slave must have been started with the appropriate address = */ - if (!sc->started || (sc->started & LSB)) + if (!sc->started) return (EINVAL); =20 return (IICBUS_WRITE(device_get_parent(bus), buf, len, sent, = timeout)); @@ -262,7 +262,7 @@ struct iicbus_softc *sc =3D (struct iicbus_softc = *)device_get_softc(bus); =09 /* a slave must have been started with the appropriate address = */ - if (!sc->started || !(sc->started & LSB)) + if (!sc->started) return (EINVAL); =20 return (IICBUS_READ(device_get_parent(bus), buf, len, read, = last, delay)); While trying to figure this out, I also came across the panic in = sys/dev/gpio/gpiobus.c:panic("rb_cpldbus: cannot serialize the access to = device."). I'm not sure how I triggered it (the backtrace wasn't = immediately revealing to me), but I'm speculating that the I2C fails to = relinquish the GPIO when a bus transaction is aborted. Stefan --=20 Stefan Bethke Fon +49 151 14070811