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

[Andrew Jeffery]

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