On 10 May 2017 at 14:55, Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> wrote: > On 05/10/2017 12:24 PM, Lorenzo Pieralisi wrote: >> >> On Tue, May 09, 2017 at 07:20:48PM +0300, Andy Shevchenko wrote: >>>>> >>>>> It means either ID is not added to drivers/acpi/acpi_apd.c or >>> >>> >>> Just one question, did you look at all into above driver? >>> I suppose it missed ID and properties for the device. >> >> >> I looked into it yes. I have also looked at ACPI tables and they >> contain the SSCN and FMCN methods and AFAIK the set-up was working >> fine before the commit in $SUBJECT - AMD guys - please correct me >> if I am wrong, I found this thread which explains things a bit: >> >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-December/395983.html >> >> If we have to patch drivers/acpi/acpi_apd.c to restore the previous >> behaviour that's fine by me but this is a regression nonetheless unless >> someone explains to me why the current firmware set-up (with SSCN and >> FMCN) is unreliable/deprecated, it is not clear to me at all and it >> may affect other platforms too. >> > I guess best would be to fix the i2c_dw_init(). Maybe by moving timing > parameters settings out to another function, do setting only for selected > speed and calculate only once in case parameters are not set. > > I don't think timing parameters for standard or fast speeds are not needed > unless operating at those speeds but have to check that first. At least > that's what we are doing for high speed. > Commit bd698d24b1b57 is broken and should be reverted: the splat on AMD Seattle is the most visible symptom, but the logic change results in DW_IC_SS_SCL_HCNT/DW_IC_SS_SCL_LCNT possibly being set to different values than specified by the ACPI methods. The missing clock splat is only a symptom of this: the driver tries to calculate values from the clock frequency that should have been read from the DSDT. For reference, this is the description we have on the platform in question: Method (SSCN, 0, NotSerialized) { Return (Package (0x03) { 0x0430, 0x04E1, 0x00 }) } Method (FMCN, 0, NotSerialized) { Return (Package (0x03) { 0x00DE, 0x018F, 0x00 }) } Whether it hurts to program different standard mode values here is irrelevant. It is simply wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
