Hello, At the request of Wolfram[1] I'm proposing two patches for inclusion in the stable tree for v4.13: [1] https://lkml.org/lkml/2017/8/29/111 Subject: i2c: aspeed: add proper support fo 24xx clock params Commit ID: 87b59ff8d1d9d809c014a4e20bc043064b6e0047 Justification: The commit message of 87b59ff8d1d9 suggests: This also fixes a potential issue where clock dividers were rounded down instead of up. This turns out to be true in practice: Whilst investigating problems with some I2C devices on an AST2500 system, it was observed via a scope that the bus was marginally overclocked with respect to both the requested bus speed and the maximum bus speed for the misbehaving device. 87b59ff8d1d9 resolved the problem, bringing the bus speed back in-spec for the device. Up front, the patch violates one of the stable rules by being slightly too large, however it does fix a real-world issues, both for the AST2400 and the AST25xx, and as such I think it's worth consideration. Subject: i2c: aspeed: Retain delay/setup/hold values when configuring bus frequency Commit ID: 95fd3ad9cd5f8a4bb01215b846a3c8e6adefe21c Justification: The commit message explains: aspeed_i2c_init_clk() was performing a direct write of the generated clock values rather than a read/mask/modify/update sequence to retain tBUF, tHDSTA and tACST, and therefore cleared the tBUF, tHDSTA and tACST fields on the AST2400. This resulted in a delay/setup/hold time of 1 base clock, which in some configurations is not enough for some devices (e.g. the MAX31785 fan controller, with an APB of 48MHz and a desired bus speed of 100kHz). The result in this instance was, that without the patch, the MAX31785 device was not accessible on the bus. As a note, 95fd3ad9cd5f depends on 87b59ff8d1d9, though as mentioned 87b59ff8d1d9 stands as a fix in its own right. Cheers, Andrew
Attachment:
signature.asc
Description: This is a digitally signed message part