On Sun, Sep 24, 2017 at 11:35:56AM -0700, Stephen Graf wrote: > I just checked the Allwinner A10 documentation (for which the driver was > written) and this is definitely a reverse of the H3. H3 says write '1' and > A10 says write '0'. >
Oh, great :) that info will help the dev w/H3-hw, to make the driver bend for the differences like it should. btw. i'm almost done shoveling w/luserland iic bus access, i haven't done much like this, and i got distracted for a while just digging deeper on both sides of the fence trying to get horrible smarts written for it all- around, or so i think when looking at it now in retrospect:) i'll trim it down back to securelevel < 1 config/simple fdt override, and/or simple 'allowed ranges/devices'-impl., and share here on arm@, as i believe it'd be futile attempt when the #ifdef notyet is nearly 15years old by now :) -Artturi > -----Original Message----- > From: owner-...@openbsd.org [mailto:owner-...@openbsd.org] On Behalf Of > Stephen Graf > Sent: Sunday, September 24, 2017 11:19 AM > To: 'aa e30' <artturi....@gmail.com>; arm@openbsd.org > Subject: possible bug in sxitwi.c for orange pi one (H3) > > I think I have found the problem with the sxitwi driver. > > > > After your note about the uart working and using the same clock as i2c, I > turned my attention back to the sxidriver. > > > > I noted that there is no clear indication in the Allwinner documentation on > how to clear the INT_FLAG bit once it is set. The text on page 445 in the > Allwinner H3 data sheet re the INT_FLAG says that in slave mode the clock is > held low until the INT_FLAG bit is written as '1'. This is what I am seeing > even though the device is in master mode. The driver currently sets it to > '0' after a status change. > > > > I changed the code to set the bit after a status change and the data started > flowing! > > > > I think this may have to do it in a number of places. I would rather the > author of this driver do it properly. > >
