Date: Wed, 7 Oct 2020 11:33:16 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: "freebsd-arm@freebsd.org" <arm@FreeBSD.org> Subject: Re: nanopi/allwinner i2c not working. Message-ID: <82ac00f2-0463-3861-dd39-9c079978be27@FreeBSD.org> In-Reply-To: <FB320D2F-610B-4773-83FD-681270F743AB@cs.huji.ac.il> References: <234D06ED-C99F-477E-8D95-492979084E7A@cs.huji.ac.il> <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> <FB320D2F-610B-4773-83FD-681270F743AB@cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/10/2020 10:54, Daniel Braniss wrote: > with D26049: > i2s -s works with and without debug > > my test runs ok with debug on, but failed with debug off. > timing issue? That's interesting. I also have an H3-based system and did not see anything like that with any of I2C devices that I have. The latest driver is completely interrupt driven and there are no fixed delays. The controller datasheet does not seem to mandate any delays as well. Perhaps the problem is on the device's side? Also, it could be that the older driver (in 12.1) was slower, so more forgiving of any wiring / connector problems. Not sure how to proceed when debug mode works fine and non-debug fails. Perhaps DTrace would be less overhead than the debug printf-s. Ah, another thought, with debugging enabled, could you please do a bus reset and see what mode and clock param get printed? -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?82ac00f2-0463-3861-dd39-9c079978be27>