On Tue, May 09, 2017 at 07:20:48PM +0300, Andy Shevchenko wrote: > On Tue, 2017-05-09 at 16:52 +0100, Lorenzo Pieralisi wrote: > > [+ Ken, Jeff] > > > > On Tue, May 09, 2017 at 05:54:11PM +0300, Andy Shevchenko wrote: > > > On Tue, 2017-05-09 at 15:07 +0100, Lorenzo Pieralisi wrote: > > > > Hi guys, > > > > > > > > as a heads-up, with today mainline (commit 2868b2513aa7) I get the > > > > following splat on AMD Seattle, reverting the $SUBJECT commit > > > > "solves" > > > > the problem. > > > > > > > > My I2C knowledge is a bit limited but I am not sure I understand > > > > why > > > > we should be reading eg ss_hcnt/ss_lcnt depending on the dev- > > > > >clk_freq > > > > but then i2c_dw_init() _always_ requires those values to be set > > > > for > > > > a given device. Again, I have no insights into I2C inner workings > > > > so apologies for the silly assumption/question. > > > > > > > > Please have a look into this, thanks. > > > > > > Since there is no clock defined you got a warning. > > > > IIUC there has never been a clock defined for this platform, that's > > the problem. The warning appeared because the commit in $SUBJECT > > prevents reading the ss_hcnt and ss_lcnt values from ACPI methods > > that are there in ACPI tables (SSCN and FMCN), because it carries > > out the SSCN FMCN look-up depending on the dev->clk_freq value. > > > > Before $SUBJECT commit the values were read unconditionally from SSCN > > and FMCN ACPI methods IIUC, again, I am no I2C expert so it is more > > a question than anything else. > > > > dev->clk_freq is set to 400000 by default because FW does not the > > contain (ie never contained) "clock-frequency" property and > > acpi_speed can't be ascertained through I2C resources, that's how > > I read what's happening. > > > > > 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. Thanks, Lorenzo -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
