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 i
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
pos
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, o
> 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
> 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
> 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
> 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 timeo
