Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Apr 2019 16:28:57 +0300
From:      Daniel Braniss <danny@cs.huji.ac.il>
To:        Emmanuel Vadot <manu@bidouilliste.com>
Cc:        "freebsd-arm@freebsd.org" <arm@freebsd.org>, Ian Lepore <ian@freebsd.org>
Subject:   Re: i2c almost working for me, was Re: i2c still not working for me
Message-ID:  <6D8540BA-2612-4FB6-B364-5D9D6569CC46@cs.huji.ac.il>
In-Reply-To: <20190425150142.bab9fb212c6c7704fdf950d8@bidouilliste.com>
References:  <12F641C3-9FAA-4A3A-BA18-A7302F3A0F5E@cs.huji.ac.il> <20190409095819.c560dbc156c46e5ca0244e3e@bidouilliste.com> <23A47048-642A-481C-B7BE-B61E55F82955@cs.huji.ac.il> <20190409171604.GA4581@bluezbox.com> <FCA4E00E-455A-46BF-AD78-E20E1E997BFC@cs.huji.ac.il> <6119CE3B-6042-4DDC-82BE-B0C0C7ADA838@cs.huji.ac.il> <5D4799BC-08DF-4F3D-81A4-C2D938F4AF93@cs.huji.ac.il> <20190417222601.c037efe0cb48987c81032bac@bidouilliste.com> <DDDAC739-D68F-4843-BF89-3044ED442F69@cs.huji.ac.il> <64b5598e2c8c7265f89a31b1f191cb1be318788a.camel@freebsd.org> <CD499934-6E4E-4416-9B73-F3B8AB9A916D@cs.huji.ac.il> <20190419100502.5546770a5795c20e3f4fa9db@bidouilliste.com> <0FDE4A01-D79E-4AFE-BA4C-3F39C4360AF8@cs.huji.ac.il> <20190424130211.7a575f57150882eb3dfabc76@bidouilliste.com> <20190424131517.140d6d4839d2435e08b67d43@bidouilliste.com> <7554C2C1-9FC1-4945-AC1B-2EB115A22D4E@cs.huji.ac.il> <D154835B-8728-4062-89DE-E8DACA7B07F9@cs.huji.ac.il> <20190425150142.bab9fb212c6c7704fdf950d8@bidouilliste.com>

next in thread | previous in thread | raw e-mail | index | archive | help


> On 25 Apr 2019, at 16:01, Emmanuel Vadot <manu@bidouilliste.com> =
wrote:
>=20
> On Thu, 25 Apr 2019 10:37:05 +0300
> Daniel Braniss <danny@cs.huji.ac.il <mailto:danny@cs.huji.ac.il>> =
wrote:
>=20
>>=20
>>=20
>>> On 24 Apr 2019, at 16:06, Daniel Braniss <danny@cs.huji.ac.il> =
wrote:
>>>=20
>>>=20
>>>=20
>>>> On 24 Apr 2019, at 14:15, Emmanuel Vadot <manu@bidouilliste.com> =
wrote:
>>>>=20
>>>> On Wed, 24 Apr 2019 13:02:11 +0200
>>>> Emmanuel Vadot <manu@bidouilliste.com =
<mailto:manu@bidouilliste.com>> wrote:
>>>>=20
>>>>> On Fri, 19 Apr 2019 11:35:09 +0300
>>>>> Daniel Braniss <danny@cs.huji.ac.il> wrote:
>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On 19 Apr 2019, at 11:05, Emmanuel Vadot <manu@bidouilliste.com> =
wrote:
>>>>>>>=20
>>>>>>> On Fri, 19 Apr 2019 10:20:47 +0300
>>>>>>> Daniel Braniss <danny@cs.huji.ac.il =
<mailto:danny@cs.huji.ac.il>> wrote:
>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On 18 Apr 2019, at 17:19, Ian Lepore <ian@freebsd.org> wrote:
>>>>>>>>>=20
>>>>>>>>> On Thu, 2019-04-18 at 10:12 +0300, Daniel Braniss wrote:
>>>>>>>>>>> On 17 Apr 2019, at 23:26, Emmanuel Vadot =
<manu@bidouilliste.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>> On Tue, 16 Apr 2019 09:16:02 +0300
>>>>>>>>>>> Daniel Braniss <danny@cs.huji.ac.il =
<mailto:danny@cs.huji.ac.il>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> On 11 Apr 2019, at 09:56, Daniel Braniss =
<danny@cs.huji.ac.il>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> if no device is connected, I2CRDWR hangs,=20
>>>>>>>>>>>>> it also happens with i2c(8) -s, only reboot helps.
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> ichb1: twsi_reset: Using IIC_FASTEST/UNKNOWN mode with =
speed
>>>>>>>>>>>>> param=3D2a
>>>>>>>>>>>>> iichb1: TWSI_WRITE: Writing 0 to 18
>>>>>>>>>>>>> iichb1: TWSI_WRITE: Writing 2a to 14
>>>>>>>>>>>>> iichb1: TWSI_WRITE: Writing 40 to c
>>>>>>>>>>>>> iichb1: TWSI_WRITE: Writing c4 to c
>>>>>>>>>>>>> iichb1: twsi_transfer: transmitting 2 messages
>>>>>>>>>>>>> iichb1: TWSI_READ: read f8 from 10
>>>>>>>>>>>>> iichb1: twsi_transfer: status=3Df8
>>>>>>>>>>>>> iichb1: twsi_transfer: msg[0] flags: 0
>>>>>>>>>>>>> iichb1: twsi_transfer: msg[0] len: 9
>>>>>>>>>>>>> iichb1: TWSI_WRITE: Writing e4 to c
>>>>=20
>>>> So looking at this is seems that the "START condition transmitted"
>>>> interrupt is never triggered, I'll see to add some type of timeout
>>>> around the pause_sbt.
>>>=20
>>> GREAT! I was about to send you a Nanopi-neo ?,=20
>>> I might just do that if you send me an address.
>>>=20
>> this patch is not that elegant, but works for me:
>> Index: twsi.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
>> --- twsi.c	(revision 346538)
>> +++ twsi.c	(working copy)
>> @@ -458,8 +458,15 @@
>> 		if (sc->msg->len =3D=3D 1)
>> 			sc->control_val &=3D ~TWSI_CONTROL_ACK;
>> 		TWSI_WRITE(sc, sc->reg_control, sc->control_val | =
TWSI_CONTROL_START);
>> -		while (sc->error =3D=3D 0 && sc->transfer !=3D 0) {
>> -			pause_sbt("twsi", SBT_1MS * 30, SBT_1MS, 0);
>> +		{
>> +			 int count =3D 10;
>> +			 while (sc->error =3D=3D 0 && sc->transfer !=3D =
0) {
>> +				  pause_sbt("twsi", SBT_1MS * 30, =
SBT_1MS, 0);
>> +				  if(count-- =3D=3D 0) {
>> +					   sc->error =3D EDEADLK;
>> +					   break;
>> +				  }
>> +			 }
>> 		}
>>=20
>> 		debugf(dev, "Done with msg[%d]\n", i);
>=20
> I think that pause_sbt returns non-zero if the time has elapsed so
> check this will possibly be enough.
> I'm more interested on why the controller didn't triggered an
> interrupt.

from my signal analyser I can see that nothing is xmitted, may be this a =
clue?

>=20
>>> danny
>>>=20
>>>>=20
>>>>>>>>>>>>> and now it?s hung
>>>>>>>>>>>>=20
>>>>>>>>>>>> [?]
>>>>>>>>>>>=20
>>>>>>>>>>> I don't see that on my OrangePi One or Pine64-LTS.
>>>>>>>>>>=20
>>>>>>>>>> well, mine is are Nanopi Neo, maybe it?s a dts issue?
>>>>>>>>>> I also have a orangepi-zero but it will take me some time to =
make
>>>>>>>>>> a sdcard
>>>>>>>>=20
>>>>>>>> I managed to boot my OrangePi Zero, and i2c -s has no issues, =
does not hang.
>>>>>>>> still, with the latest (r346368) my NanoPi Neo hangs when no =
i2c device is present,
>>>>>>>> so what is the difference? or where can I look?
>>>>>>>=20
>>>>>>> Are you using the same i2c controller on both ?
>>>>>> yes, and have tested with several controllers and nanopies,=20
>>>>>>=20
>>>>>>> Could you paste somewhere the overlays or dts patches ?
>>>>>> cat ./allwinner/dts/12/h3-i2c.dtso
>>>>>> /dts-v1/;
>>>>>> /plugin/;
>>>>>>=20
>>>>>> //#include "sun8i-h3-nanopi-neo.dts"
>>>>>>=20
>>>>>> / {
>>>>>> compatible =3D "allwinner,sun8i-h3";
>>>>>> };
>>>>>>=20
>>>>>> &i2c0 {
>>>>>>       ##frequency =3D <50000>;
>>>>>>       status =3D "okay";
>>>>>> };
>>>>>>=20
>>>>>> &i2c1 {
>>>>>>       ##frequency =3D <50000>;
>>>>>>       status =3D "okay";
>>>>>> };
>>>>>>=20
>>>>>>=20
>>>>>=20
>>>>> And you have hang on both i2c0 and i2c1 ?
>>>>> Also please note that i2c1 pins aren't routed on this PCB, I don't
>>>>> think that this could/should make the i2c controller hangs but ...
>>>>>=20
>>>>> --=20
>>>>> Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
>>>>> _______________________________________________
>>>>> freebsd-arm@freebsd.org <mailto:freebsd-arm@freebsd.org> mailing =
list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm =
<https://lists.freebsd.org/mailman/listinfo/freebsd-arm>;
>>>>> To unsubscribe, send any mail to =
"freebsd-arm-unsubscribe@freebsd.org =
<mailto:freebsd-arm-unsubscribe@freebsd.org>"
>>>>=20
>>>>=20
>>>> --=20
>>>> Emmanuel Vadot <manu@bidouilliste.com =
<mailto:manu@bidouilliste.com>> <manu@freebsd.org =
<mailto:manu@freebsd.org>>
>>>=20
>>> _______________________________________________
>>> freebsd-arm@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>> To unsubscribe, send any mail to =
"freebsd-arm-unsubscribe@freebsd.org"
>=20
>=20
> --=20
> Emmanuel Vadot <manu@bidouilliste.com <mailto:manu@bidouilliste.com>> =
<manu@freebsd.org <mailto:manu@freebsd.org>>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6D8540BA-2612-4FB6-B364-5D9D6569CC46>