On Tue, Apr 25, 2017 at 2:47 AM, Ryan Chen <ryan_chen@xxxxxxxxxxxxxx> wrote: > Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as well please ? > > About ASPEED_I2CD_M_HIGH_SPEED_EN, it is support for I2C specification "High speed transfer". And also device need support it. > If you just speed up the I2C bus clock, you don’t have to enable ASPEED_I2CD_M_HIGH_SPEED_EN, just change the clock is ok. > Interesting, I thought that ASPEED_I2CD_M_SDA_DRIVE_1T_EN and its counterpart would be used for fast mode or fast mode plus and ASPEED_I2CD_M_HIGH_SPEED_EN would be used for fast mode plus or high speed mode and that they work by driving the SDA and SCL signals to improve rise times. It made sense to me because the lowest SCL you can get with base clock set to zero is about ~1.5MHz which is in between fast mode plus (1MHz) and high speed mode (3.4MHz). But from what you are saying, ASPEED_I2CD_M_SDA_DRIVE_1T_EN and its counterpart are totally orthogonal to the selected speed and ASPEED_I2CD_M_HIGH_SPEED_EN exists as a matter of convenience to set all of the divider registers to their smallest possible values. Is my understanding correct? > > -----Original Message----- > From: Benjamin Herrenschmidt [mailto:benh@xxxxxxxxxxxxxxxxxxx] > Sent: Tuesday, April 25, 2017 5:35 PM > To: Ryan Chen <ryan_chen@xxxxxxxxxxxxxx>; Brendan Higgins <brendanhiggins@xxxxxxxxxx> > Cc: Wolfram Sang <wsa@xxxxxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Mark Rutland <mark.rutland@xxxxxxx>; Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Jason Cooper <jason@xxxxxxxxxxxxxx>; Marc Zyngier <marc.zyngier@xxxxxxx>; Joel Stanley <joel@xxxxxxxxx>; Vladimir Zapolskiy <vz@xxxxxxxxx>; Kachalov Anton <mouse@xxxxxxx>; Cédric Le Goater <clg@xxxxxxxx>; linux-i2c@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; Linux Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>; OpenBMC Maillist <openbmc@xxxxxxxxxxxxxxxx> > Subject: Re: [PATCH v6 4/5] i2c: aspeed: added driver for Aspeed I2C > > On Tue, 2017-04-25 at 08:50 +0000, Ryan Chen wrote: >> Hello All, >> ASPEED_I2CD_M_SDA_DRIVE_1T_EN, >> ASPEED_I2CD_SDA_DRIVE_1T_EN is specific for some case usage. >> For example, if i2c bus is use on "high speed" and "single slave and >> master" and i2c bus is too long. It need drive SDA or SCL less lunacy. >> It would enable it. >> Otherwise, don’t enable it. especially in multi-master. >> It can’t be enable. > > That smells like a specific enough use case that we should probably cover with a device-tree property, something like an empty "sda-extra-drive" property (empty properties are typically used for booleans, their presence means "true"). > > Thanks Ryan. Can you shed some light on the meaning of the high-speed bit as well please ? Does it force to a specific speed (ignoring the > divisor) or we can still play with the clock high/low counts ? > ... >> > Your latest patch still does that. It will do things like start a >> > STOP command *then* ack the status bits. I'm pretty sure that's >> > bogus. >> > >> > That way it's a lot simpler to simply move the >> > >> > writel(irq_status, bus->base + ASPEED_I2C_INTR_STS_REG); >> > >> > To either right after the readl of the status reg at the beginning >> > of aspeed_i2c_master_irq(). >> > >> > I would be very surprised if that didn't work properly and wasn't >> > much safer than what you are currently doing. >> >> I think I tried your way and it worked. In anycase, Ryan will be able >> to clarify for us. After thinking about this more, I think Ben is right. It would be unusual for such a common convention to be broken and even if it is, I do not see how a command could take effect until it is actually issued. Nevertheless, it would make me feel better if you, Ryan, could comment on this. >> >> > >> > > Let me know if you still think we need a "RECOVERY" state. >> > ... I feel pretty good about this; it does not look like there will be a lot of changes going into v8; hopefully, that version will be good enough to get merged. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
