On 2018-05-08 10:06, Mike Looijmans wrote:
> On 08-05-18 08:36, Peter Rosin wrote:
>> On 2018-05-01 13:42, Mike Looijmans wrote:
>>> Instead of just hogging the reset GPIO into deactivated state, activate and
>>> then de-activate the reset. This allows for better recovery if the CPU was
>>> reset h
On 08-05-18 08:36, Peter Rosin wrote:
On 2018-05-01 13:42, Mike Looijmans wrote:
Instead of just hogging the reset GPIO into deactivated state, activate and
then de-activate the reset. This allows for better recovery if the CPU was
reset halfway through an I2C transaction for example.
I can't
On 2018-05-01 13:42, Mike Looijmans wrote:
> Instead of just hogging the reset GPIO into deactivated state, activate and
> then de-activate the reset. This allows for better recovery if the CPU was
> reset halfway through an I2C transaction for example.
I can't see any problems with this, and a re
Instead of just hogging the reset GPIO into deactivated state, activate and
then de-activate the reset. This allows for better recovery if the CPU was
reset halfway through an I2C transaction for example.
Signed-off-by: Mike Looijmans
---
drivers/i2c/muxes/i2c-mux-pca954x.c | 12 ++--
1
4 matches
Mail list logo