Re: i2c and indirect vs. direct config
> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I note that the gpioow, a onewire bus, may have simular ghost issues as > i2c: It’s literally impossible to probe for devices on raw GPIO — we really should do hard-and-fast locators in that scenario. -- thorpej
Re: i2c and indirect vs. direct config
> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > Unfortunate behavior. Looking back over the sensor driver I worked on, > it appears that I always read something to determine if the device was > actually there. I spent some time reviewing NXP’s i2c spec this evening (well, during timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle error in our i2c_bitbang code… the spec seems pretty clear that a START-address-ACK should occur if a device is really there, and thus the “quick read” method for device detection should work 100% of the time. I suspect we’re not properly setting the SDA line as an input at the critical time… we should be ensuring that any internal pull-up is activated so that any responding slave really does have to drive the line low, so that we can get a clear reading on the ACK. I might experiment with this using an external pull-up to see if the ghosting behavior goes away with the “quick read”. (Not sure I'll get to it this weekend, though… despite my kid’s spring soccer season being finished, I seem to have a full calendar nonetheless…) -- thorpej
Re: i2c and indirect vs. direct config
> On May 31, 2018, at 6:14 PM, Brad Spencer wrote: > > I wonder if the i2c bus attachments should have the option of being > treated like gpio attachements with a new command... probably a lot of > work: > > iicctl iic2 attach dstrc 0x68 3231 I’ve been thinking about this. I think we could wrap all of the functionality into drvctl, and allow it to specify arbitrary locators. The locator names could be string-matched-and-validated in the kernel to get them into the right cf_loc[] slots. Consider it “in the queue” :-) -- thorpej
Re: i2c and indirect vs. direct config
> On May 31, 2018, at 9:34 PM, Jason Thorpe wrote: > > I spent some time reviewing NXP’s i2c spec this evening (well, during > timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle > error in our i2c_bitbang code… *smacks forehead* … RPI, of course, has a “smart” i2c controller. There may be a bug in that driver. What I should do is try gpioiic to see if the “quick read” method works there. Same caveat as below applies, however. > (Not sure I'll get to it this weekend, though… despite my kid’s spring soccer > season being finished, I seem to have a full calendar nonetheless…) -- thorpej
Re: i2c and indirect vs. direct config
Jason Thorpe writes: >> On May 31, 2018, at 9:34 PM, Jason Thorpe wrote: >> >> I spent some time reviewing NXP’s i2c spec this evening (well, during >> timeouts, etc. — GO DUBS), and I’m becoming convinced that there is a subtle >> error in our i2c_bitbang code… > > *smacks forehead* … RPI, of course, has a “smart” i2c controller. There may > be a bug in that driver. What I should do is try gpioiic to see if the > “quick read” method works there. > > Same caveat as below applies, however. > >> (Not sure I'll get to it this weekend, though… despite my kid’s spring >> soccer season being finished, I seem to have a full calendar nonetheless…) > > -- thorpej gpioiic may have bugs too.. I could not get it to work with the am2315. Reads would not error, but no data was returned. However, the am2315 is a strange thing. However, the si70xxtemp(4) driver did work with gpioiic. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
re: Audio update pertaining to mixer devices and hw.driverN.multiuser
hi Nat, i object to the plan here. we should simply just use the file system to control this, like normal unix stuff. eg, ttyaction should chown the audio device to the console user or whatever the admin chooses. it should be possible for me to decide to make things as open or as closed as possible via chown/chmod/mknod/rm. thanks. .mrg.
Re: i2c and indirect vs. direct config
On Thu, 31 May 2018, Jason Thorpe wrote: I spent some time reviewing NXP???s i2c spec this evening (well, during timeouts, etc. ??? GO DUBS), and I???m becoming convinced that there is a subtle error in our i2c_bitbang code??? the spec seems pretty clear that a START-address-ACK should occur if a device is really there, and thus the ???quick read??? method for device detection should work 100% of the time. ... There is at least one i2c bus controller that explicitly doesn't handle "quick" transactions - the imc controller built into the Intel X99 chip-set. The docs are pretty clear that it implements an absolute minimum subset of i2c, just barely enough to talk to the SPD ROMs on memory DIMMs. +--+--++ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org | +--+--++
