[PATCH dev-5.2 0/2] i2c: aspeed: Add H/W timeout support

[Jae Hyun Yoo]

On 9/11/2019 6:22 PM, Andrew Jeffery wrote:
> 
> 
> On Thu, 12 Sep 2019, at 04:26, Jae Hyun Yoo wrote:
>> Hi Andrew,
>>
>> On 9/4/2019 5:54 PM, Jae Hyun Yoo wrote:
>>> On 9/4/2019 5:10 PM, Andrew Jeffery wrote:
>>>>
>>>>
>>>> On Thu, 5 Sep 2019, at 09:10, Jae Hyun Yoo wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> On 9/4/2019 4:12 PM, Andrew Jeffery wrote:
>>>>>> On Thu, 5 Sep 2019, at 08:31, Jae Hyun Yoo wrote:
>>>>>>> Hi Joel,
>>>>>>>
>>>>>>> On 9/4/2019 3:54 PM, Joel Stanley wrote:
>>>>>>>> Hi Jae,
>>>>>>>>
>>>>>>>> On Wed, 4 Sep 2019 at 20:08, Jae Hyun Yoo
>>>>>>>> <jae.hyun.yoo at linux.intel.com> wrote:
>>>>>>>>>
>>>>>>>>> In case of multi-master environment, if a peer master incorrectly
>>>>>>>>> handles
>>>>>>>>> a bus in the middle of a transaction, I2C hardware hangs in slave
>>>>>>>>> state
>>>>>>>>> and it can't escape from the slave state, so this commit adds slave
>>>>>>>>> inactive timeout support to recover the bus in the case.
>>>>>>>>>
>>>>>>>>> By applying this change, SDA data-low and SCL clock-low timeout
>>>>>>>>> feature
>>>>>>>>> also could be enabled which was disabled previously.
>>>>>>>>
>>>>>>>> Please consider sending your RFC patches to the upstream list. You
>>>>>>>> have a big backlog of patches now.
>>>>>>>
>>>>>>> Thanks for the reminding. I can't send the RFC patches yet because
>>>>>>> QEMU
>>>>>>> H/W model isn't ready yet. I'm still waiting for the fix from Cedric.
>>>>>>
>>>>>> QEMU shouldn't be preventing you from sending patches upstream, rather
>>>>>> it prevents us from enabling the buffer mode support in the OpenBMC
>>>>>> kernel tree. You should be sending all patches upstream as early as
>>>>>> possible.
>>>>>
>>>>> I met a QEMU issue when I was upstreaming a patch set last year:
>>>>> https://lists.ozlabs.org/pipermail/linux-aspeed/2018-September/000750.html
>>>>>
>>>>>
>>>>> If OpenBMC community accepts the QEMU issue, I can submit the RFC
>>>>> patches to upstream. Will submit the patch set soon to linux tree.
>>>>
>>>> Ah, didn't realise it was Guenter that ran into it. We have some
>>>> changes[1] in
>>>> Cedric's aspeed-4.2 qemu tree - do you mind testing it out? If those
>>>> patches
>>>> resolve the issue Maybe we could point Guenter at that tree, though
>>>> really we
>>>> should get the fixes upstream so this isn't an issue.
>>>>
>>>> [1]
>>>> https://github.com/legoater/qemu/compare/59dda66ab756e52e6a9c1ef89660d30b3769f63c...aspeed-4.2
>>>>
>>>>
>>>
>>> Okay. I'll give it a try.
>>
>> I've tested I2C buffer mode support in QEMU using:
>> git://github.com/legoater/qemu.git
>> SRCBRANCH = "aspeed-4.2"
>> SRCREV = "1b31d645c448858eb7d11d463a4cb77df0ee7923"
> 
> This looks like changes to the qemu bitbake recipe? Have you
> integrated openbmc/qemu into Yocto's runqemu infrastructure,
> or were you just using bitbake to build qemu? I'd love to see
> patches if you've done the former :)
> 
> Andrew
> 

No, I just made this change using a bbappend in my local yocto tree.
The source revision on the branch worked well.

Jae