Date: Wed, 7 Oct 2020 10:54:54 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Andriy Gapon <avg@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" <arm@FreeBSD.org> Subject: Re: nanopi/allwinner i2c not working. Message-ID: <FB320D2F-610B-4773-83FD-681270F743AB@cs.huji.ac.il> In-Reply-To: <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <d154f62f-cf41-aaac-4bae-89ee48163afa@FreeBSD.org> <E2E23A4F-9D51-4803-BFF1-B5B2BBE56576@cs.huji.ac.il> <7934CE38-DC3F-450A-A131-19A7F88DA9EC@cs.huji.ac.il> <e1dd71e2-9ee3-380d-7be9-601a3015652c@FreeBSD.org> <20201006104119.28f2262d47107d41025d193f@bidouilliste.com> <29A34854-E792-48CE-AF0A-E4C605BDFC3B@cs.huji.ac.il> <6416CA90-AB4C-4F8A-BCF4-7C9E5A4F2F8D@cs.huji.ac.il> <0ba109b4-784f-19ed-e52d-a40b75af872c@FreeBSD.org> <7C27FB6C-BF0D-4DAE-99D0-50849D2FBA5E@cs.huji.ac.il> <ecc5c0cf-3a5f-ef24-8270-3b95354ee7d9@FreeBSD.org> <F36B7EDD-B9A8-4D9B-854E-B54BFE678AB9@cs.huji.ac.il> <43a5d626-634c-2cc2-e8a5-ad4326a2d6e2@FreeBSD.org> <77DC054E-07B2-48F8-8051-C2796EE991B2@cs.huji.ac.il> <ec611752-8c5f-c4e7-18f2-bafd4a34e594@FreeBSD.org> <260839FF-7297-4FDC-82AC-13797938AC29@cs.huji.ac.il> <f926a7c2-e4c4-5cee-69fa-80a53182bd98@FreeBSD.org> <9FE1F947-4975-411C-91D1-94C43E5495C8@cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 7 Oct 2020, at 10:21, Daniel Braniss <danny@cs.huji.ac.il> wrote: >=20 >=20 >=20 >> On 7 Oct 2020, at 09:32, Andriy Gapon <avg@FreeBSD.org> wrote: >>=20 >> On 06/10/2020 23:29, Daniel Braniss wrote: >>>=20 >>>=20 >>>> On 6 Oct 2020, at 17:22, Andriy Gapon <avg@FreeBSD.org >>>> <mailto:avg@FreeBSD.org>> wrote: >>>>=20 >>>> On 06/10/2020 17:00, Daniel Braniss wrote: >>>>> not too proud of it, but i=E2=80=99ll make it available. >>>>> it=E2=80=99s in https://www.cs.huji.ac.il/~danny/elockc.tar.bz >>>>> look in i2c.c >>>>>=20 >>>>> in any case it works fine in 12.1. >>>>=20 >>>> And it looks good to me as well. >>>> Could you please collect twsi debug output again? >>>> In head you do not need to recompile, you can just set = hw.i2c.twsi_debug. >>> i did have to recompile >>=20 >> Oh, I thought I committed that change, but now I see that I have not. >> It is a part of D26049. >>=20 >>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >>> iichb0: twsi_reset: Using clock param=3D59 >>> iichb0: TWSI_WRITE: Writing 0 to 18 >>> iichb0: TWSI_WRITE: Writing 59 to 14 >>> iichb0: TWSI_WRITE: Writing 40 to c >>> iichb0: twsi_calc_baud_rate: Bus clock is at 24000000 >>> iichb0: twsi_reset: Using clock param=3D59 >>> iichb0: TWSI_WRITE: Writing 0 to 18 >>> iichb0: TWSI_WRITE: Writing 59 to 14 >>> iichb0: TWSI_WRITE: Writing 40 to c >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_transfer: transmitting 2 messages >>> iichb0: TWSI_READ: read f8 from 10 >>> iichb0: twsi_transfer: status=3Df8 >>> iichb0: twsi_transfer: msg 0 is 9 bytes long >>> iichb0: twsi_transfer: msg 1 is 7 bytes long >>> iichb0: TWSI_WRITE: Writing e4 to c >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 8 from 10 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_intr: Send the address (48)iichb0: TWSI_WRITE: Writing = 48 to 8 >>=20 >> Does that address (0x24 / 0x48 in 7-/8-bit representations) look = correct? >=20 > 100% correct >=20 >>=20 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: TWSI_WRITE: Writing cc to c >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 20 from 10 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_intr: No ack received after transmitting the address >>=20 >> The controller says that the device did not acknowledge its address. >> In other words, no device responded to the slave address. >=20 > but i2c -s=20 >>=20 >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: twsi_transfer: pause finish >>> iichb0: TWSI_WRITE: Writing 8 to c >>> iichb0: twsi_transfer: Error, aborting (2) >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_WRITE: Writing c4 to c >>> iichb0: twsi_transfer: transmitting 2 messages >>> iichb0: twsi_intr: Got interrupt Current msg=3D0 >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: TWSI_READ: read 30 from 10 >>> iichb0: twsi_transfer: status=3D30 >>> iichb0: TWSI_READ: read cc from c >>> iichb0: twsi_transfer: msg 0 is 9 bytes long >>> iichb0: twsi_intr: reg control=3Dcc >>> iichb0: twsi_transfer: msg 1 is 7 bytes long >>>=20 >>> iichb0: twsi_intr: status=3D30 hot handled >>> iichb0: TWSI_WRITE: Writing e4 to c >>> iichb0: twsi_intr: Refresh reg_control >>> iichb0: twsi_transfer: pause finish >>> iichb0: TWSI_WRITE: Writing 8 to c >>> iichb0: twsi_transfer: Error, aborting (1) >>> iichb0: twsi_intr: Done with interrupts >>>=20 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 10 from 10 >>> iichb0: twsi_transfer: status=3D10 >>> iichb0: TWSI_WRITE: Writing 0 to c >>> iichb0: TWSI_READ: read 10 from 10 >>> iichb0: twsi_transfer: status=3D10 >>=20 >> The rest reads like gibberish because the driver did not stop the = controller >> after the NACK (also, possibly some log messages were omitted from = your email). >>=20 >> I'd recommend once again to give https://reviews.freebsd.org/D26049 a = try. >> I've just rebased it on the latest head, so it should apply cleanly. >=20 > i just downloaded it and will try - the sysctl for hw. is there. >=20 > (i did a git to get the latest current, i=E2=80=99ll try doing an svn = update later -its bloody slow) >>=20 >> But as I said earlier, from the debug log it seems that the problem = is either >> with the slave address or with the hardware (wiring, etc). >=20 > the hardware is fine, running 12.1 on it works ok. > and also i2c -s finds it. >=20 >=20 >> It's also possible that that was a transient condition. >=20 > not really, it seems to me some timming issue. >=20 > after a power cycle, and with debug on, all is working. > turning off debug only i2c -s works. >=20 > in any case will try the D26049 now. >=20 with D26049: i2s -s works with and without debug my test runs ok with debug on, but failed with debug off. timing issue? thanks, danny
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FB320D2F-610B-4773-83FD-681270F743AB>