[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 1/3] hw/i2c: core: Add reset
From: |
Joe Komlodi |
Subject: |
Re: [PATCH v3 1/3] hw/i2c: core: Add reset |
Date: |
Tue, 20 Feb 2024 11:11:43 -0800 |
On Fri, Feb 16, 2024 at 5:04 PM Corey Minyard <minyard@acm.org> wrote:
>
> On Thu, Feb 08, 2024 at 04:39:10PM +0000, Peter Maydell wrote:
> > On Fri, 2 Feb 2024 at 20:48, Joe Komlodi <komlodi@google.com> wrote:
> > >
> > > It's possible for a reset to come in the middle of a transaction, which
> > > causes the bus to be in an old state when a new transaction comes in.
> > >
> > > Signed-off-by: Joe Komlodi <komlodi@google.com>
> > > ---
> > > hw/i2c/core.c | 19 +++++++++++++++++++
> > > include/hw/i2c/i2c.h | 2 +-
> > > 2 files changed, 20 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/hw/i2c/core.c b/hw/i2c/core.c
> > > index 4cf30b2c86..3128067bba 100644
> > > --- a/hw/i2c/core.c
> > > +++ b/hw/i2c/core.c
> > > @@ -23,10 +23,29 @@ static Property i2c_props[] = {
> > > DEFINE_PROP_END_OF_LIST(),
> > > };
> > >
> > > +static void i2c_bus_hold_reset(Object *obj)
> > > +{
> > > + I2CBus *bus = I2C_BUS(obj);
> > > + I2CNode *node, *next;
> > > +
> > > + bus->broadcast = false;
> > > + QLIST_FOREACH_SAFE(node, &bus->current_devs, next, next) {
> > > + QLIST_REMOVE(node, next);
> > > + g_free(node);
> > > + }
> > > +}
> >
> > This does what it says it's going to do; but I think it
> > would be good to hear from Corey whether it's better to
> > do this, or instead to call i2c_end_transfer() in the
> > reset-enter phase.
>
> Sorry, I missed this, I'm having major chaos going on right now in my
> life.
No worries! I also missed this for a bit.
>
> I don't think i2c_end_transfer() is the right thing to do. The transfer
> has not cleanly ended, it is just forgotten.
Sounds good to me, I'll send up v4 with the change Peter pointed out.
Thanks,
Joe
>
> >
> > Mostly QEMU's "reset" is like power-cycling, in which case
> > I guess that what we have here where we just forget about
> > the in-progress transfer and assume the device on the other
> > end is also going to reset back to a neutral state is what
> > we want.
> >
> > Does i2c have a concept of a bus-level "reset" operation?
>
> No, it does not. Most I2C devices don't even have a reset pin. In a
> reset situation in real hardware, the operation would be aborted by
> the lines drifting high after the bus master has been reset.
>
> So I think this is fine as is.
>
> -corey
>
> >
> > > +
> > > +static void i2c_bus_class_init(ObjectClass *klass, void *data)
> > > +{
> > > + ResettableClass *rc = RESETTABLE_CLASS(klass);
> > > + rc->phases.hold = i2c_bus_hold_reset;
> > > +}
> > > +
> > > static const TypeInfo i2c_bus_info = {
> > > .name = TYPE_I2C_BUS,
> > > .parent = TYPE_BUS,
> > > .instance_size = sizeof(I2CBus),
> > > + .class_init = i2c_bus_class_init,
> > > };
> >
> >
> >
> > > static int i2c_bus_pre_save(void *opaque)
> > > diff --git a/include/hw/i2c/i2c.h b/include/hw/i2c/i2c.h
> > > index 2a3abacd1b..49580e30e2 100644
> > > --- a/include/hw/i2c/i2c.h
> > > +++ b/include/hw/i2c/i2c.h
> > > @@ -64,7 +64,7 @@ struct I2CSlave {
> > > };
> > >
> > > #define TYPE_I2C_BUS "i2c-bus"
> > > -OBJECT_DECLARE_SIMPLE_TYPE(I2CBus, I2C_BUS)
> > > +OBJECT_DECLARE_TYPE(I2CBus, I2CBusClass, I2C_BUS)
> >
> > I don't think you need this change any more ?
> >
> > thanks
> > -- PMM
> >