[RFC PATCH dev-5.1 4/6] i2c: aspeed: fix master pending state handling

Jae Hyun Yoo jae.hyun.yoo at linux.intel.com
Sat Jun 22 08:33:22 AEST 2019


On 6/21/2019 3:11 PM, Tao Ren wrote:
> On 6/20/19 1:34 PM, Jae Hyun Yoo wrote:
>> On 6/20/2019 1:30 PM, Tao Ren wrote:
>>> On 6/20/19 12:49 PM, Jae Hyun Yoo wrote:
>>>> In case of a master pending state, it should not trigger the master
>>>> command because this H/W is sharing the same data buffer for slave
>>>> and master operation, so this commit fixes the issue with making
>>>> the master command triggering happens when the state goes to active
>>>> state.
>>>>
>>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo at linux.intel.com>
>>>
>>> Thank you Jae for the patch. I believe I hit the bug while debugging BMC-BIC multi-master communication on my Minipack ast2500 BMC platform. Let me apply the patch and run some testing, will try to share my results by this Friday (Pacific Time).
>>
>> Thank you Tao for your help for testing it. It would be really helpful
>> to complete this patch implementation. Will wait the test results.
>>
>> Regards,
>> Jae
> 
> Hi Jae,
> 
> Although my problem is not fixed by this patch, nothing gets worse :) And patch itself looks reasonable to me.

Hi Tao,

Thanks for your review.

> 
> The problem I'm facing is: i2c-0 (multi-master) stays in "SLAVE_ACTIVE" state: slave_state is brought back to SLAVE_START again and again due to SLAVE_MATCH interrupt. I didn't get chance to check master state machine, but I'd assume it's always pending which explains why userspace applications get "connection timed out" error for i2c master transfers.

I haven't seen this issue in my machine. Probably it needs to enable
'slave timeout' feature which AST2500 provides.

Thanks,
Jae

> 
> Cheers,
> 
> Tao
> 


More information about the openbmc mailing list