> 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? In I2c specification[http://www.csd.uoc.gr/~hy428/reading/i2c_spec.pdf] there have a chapter about high speed transfer. It will start from specific command (00001XXX) and after that can transfer to high speed mode. The following is our high speed mode programming guide. That also have description at AST2400 datasheet. 40.7.12 > > -----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. ��.n��������+%������w��{.n����z�{��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
