Date: Tue, 02 Dec 2014 14:35:39 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 195009] [patch]: [arm] Use 400 kHz as the default OMAP4 I2C bus speed Message-ID: <bug-195009-7-AlBg26M1x0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-195009-7@https.bugs.freebsd.org/bugzilla/> References: <bug-195009-7@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195009 --- Comment #10 from Scott Ellis <jumpnowtek@gmail.com> --- The values chosen for the OMAP4 1MHz I2C speed aren't working for me on either a Duovero or PandaBoard { 1000000, 5, 1, 3, 0, 0}, They generate the correct SCL clock speed, but the driver times out when you make a request. It's the second mtx_sleep() in ti_i2c_transfer(), line 445 in ti_i2c.c that times out. The error you get back is EWOULDBLOCK/EAGAIN. Also either the SCL never stops running and you have to reset the bus or the SCL goes idle again (high) but you cannot run a second test without resetting the bus. You get no activity on the SCL line on subsequent attempts. I don't have an explanation, but the following values also give a 1 MHz SCL and the bus behaves properly when you use it. The error you get back is a correct ENXIO if the device is not present. And the SCL clocks only the nine bits expected. { 1000000, 3, 5, 7, 0, 0}, These values also work. { 1000000, 1, 17, 19, 0, 0}, Something about the current values chosen for 1 MHz cause problems. Here's how I'm testing the PandaBoard I2C2 (/dev/iic1). Reading SCL on J4-14 No device at the address I am accessing Custom program doing an I2CRDWR request Original { 5, 1, 3, } divider values With a 560 ohm pullup, SCL runs at 1 MHz but never stops, error is EWOULDBLOCK With a 1k ohm pullup, SCL runs at ~960 kHz, but only once without a reset, EWOULDBLOCK Using { 3, 5, 7, } divider values With a 560 ohm pullup, SCL runs ~960-985 kHz, error is ENXIO, repeated tests ok With a 1k ohm pullup, SCL runs at ~960 kHz, ENXIO, repeated tests ok I get similar results with the Duovero whether or not there is a device that can respond. With the Duovero the clock always continues running though. And just to be clear, 100kHz and 400kHz work fine using the same test app and the same busses and in the case of the Duovero, when there is a device on the other end. I can test further if there is a specific request. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-195009-7-AlBg26M1x0>