> Basically what I was asking is whether I could use i2c_generic_scl_recovery
> in the case where SCL is hung.
The name is a bit misleading, I am afraid. Recovery can only be used when
SDA is stuck low. And to fix this it *uses* SCL toggling to get out of
it. And 'generic_scl' means 'gimme some
> Basically what I was asking is whether I could use i2c_generic_scl_recovery
> in the case where SCL is hung.
The name is a bit misleading, I am afraid. Recovery can only be used when
SDA is stuck low. And to fix this it *uses* SCL toggling to get out of
it. And 'generic_scl' means 'gimme some
Sorry, went on vacation and then forgot about our conversion.
>> the struct i2c_bus_recovery_info. Is i2c_generic_scl_recovery supposed
>> to be part of the user interface, or is it just intended to help put the
>> main recovery function together?
>
> Sorry, I don't understand the question. What
Sorry, went on vacation and then forgot about our conversion.
>> the struct i2c_bus_recovery_info. Is i2c_generic_scl_recovery supposed
>> to be part of the user interface, or is it just intended to help put the
>> main recovery function together?
>
> Sorry, I don't understand the question. What
> the struct i2c_bus_recovery_info. Is i2c_generic_scl_recovery supposed
> to be part of the user interface, or is it just intended to help put the
> main recovery function together?
Sorry, I don't understand the question. What do you mean?
signature.asc
Description: PGP signature
> the struct i2c_bus_recovery_info. Is i2c_generic_scl_recovery supposed
> to be part of the user interface, or is it just intended to help put the
> main recovery function together?
Sorry, I don't understand the question. What do you mean?
signature.asc
Description: PGP signature
On Tue, Jun 27, 2017 at 2:00 AM, Wolfram Sang wrote:
>
>> > If SCL is stuck low, how do you want to send a STOP?
>> >
>>
>> Fair point. I should probably drop that in the future and just do a
>> reset, and even then, doing a
>> reset is probably just wishful thinking. If a
On Tue, Jun 27, 2017 at 2:00 AM, Wolfram Sang wrote:
>
>> > If SCL is stuck low, how do you want to send a STOP?
>> >
>>
>> Fair point. I should probably drop that in the future and just do a
>> reset, and even then, doing a
>> reset is probably just wishful thinking. If a slave is holding down
> > If SCL is stuck low, how do you want to send a STOP?
> >
>
> Fair point. I should probably drop that in the future and just do a
> reset, and even then, doing a
> reset is probably just wishful thinking. If a slave is holding down
> SCL, we are pretty screwed.
Yes, you'd need to reset the
> > If SCL is stuck low, how do you want to send a STOP?
> >
>
> Fair point. I should probably drop that in the future and just do a
> reset, and even then, doing a
> reset is probably just wishful thinking. If a slave is holding down
> SCL, we are pretty screwed.
Yes, you'd need to reset the
On Sun, Jun 25, 2017 at 11:18 PM, Joel Stanley wrote:
> On Sat, Jun 24, 2017 at 4:13 AM, Wolfram Sang wrote:
>> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>>> Added initial master support for Aspeed I2C controller. Supports
>>> fourteen
On Sun, Jun 25, 2017 at 11:18 PM, Joel Stanley wrote:
> On Sat, Jun 24, 2017 at 4:13 AM, Wolfram Sang wrote:
>> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>>> Added initial master support for Aspeed I2C controller. Supports
>>> fourteen busses present in AST24XX and AST25XX
On Fri, Jun 23, 2017 at 11:43 AM, Wolfram Sang wrote:
> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>> Added initial master support for Aspeed I2C controller. Supports
>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>
>>
On Fri, Jun 23, 2017 at 11:43 AM, Wolfram Sang wrote:
> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>> Added initial master support for Aspeed I2C controller. Supports
>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>
>> Signed-off-by: Brendan Higgins
On Sat, Jun 24, 2017 at 4:13 AM, Wolfram Sang wrote:
> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>> Added initial master support for Aspeed I2C controller. Supports
>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>
>>
On Sat, Jun 24, 2017 at 4:13 AM, Wolfram Sang wrote:
> On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
>> Added initial master support for Aspeed I2C controller. Supports
>> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>>
>> Signed-off-by: Brendan Higgins
>
On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
Applied to for-next, thanks for
On Tue, Jun 20, 2017 at 02:15:15PM -0700, Brendan Higgins wrote:
> Added initial master support for Aspeed I2C controller. Supports
> fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
>
> Signed-off-by: Brendan Higgins
Applied to for-next, thanks for all the hard work!
One
Added initial master support for Aspeed I2C controller. Supports
fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
Signed-off-by: Brendan Higgins
---
hanges for v2:
- Added single module_init (multiple was breaking some builds).
Changes for v3:
-
Added initial master support for Aspeed I2C controller. Supports
fourteen busses present in AST24XX and AST25XX BMC SoCs by Aspeed.
Signed-off-by: Brendan Higgins
---
hanges for v2:
- Added single module_init (multiple was breaking some builds).
Changes for v3:
- Removed "bus" device tree
20 matches
Mail list logo