lwn.git/drivers/i2c/busses/i2c-designware-master.c, branch docs-5.6

i2c: designware: Fix unused variable warning

2019-08-06T20:23:24+00:00

drivers/i2c/busses/i2c-designware-master.c: In function ‘i2c_dw_init_recovery_info’: drivers/i2c/busses/i2c-designware-master.c:658:6: warning: unused variable ‘r’ [-Wunused-variable] int r; ^ Fixes: 33eb09a02e8d ("i2c: designware: make use of devm_gpiod_get_optional") Signed-off-by: Shaokun Zhang Acked-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang

i2c: designware: make use of devm_gpiod_get_optional

2019-08-01T12:58:31+00:00

There is a semantical change: if devm_gpiod_get_optional returns -ENOSYS this is passed as error to the caller. This effectively reverts commit d1fa74520dcd ("i2c: designware: Consider SCL GPIO optional") which shouldn't be necessary any more since gpiod_get_optional doesn't return -ENOSYS any more with GPIOLIB=n. Signed-off-by: Uwe Kleine-König Reviewed-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang

i2c: designware: ratelimit 'transfer when suspended' errors

2019-05-02T16:26:48+00:00

There are two problems with dev_err() here. One: It is not ratelimited. Two: We don't see which driver tried to transfer something with a suspended adapter. Switch to dev_WARN_ONCE to fix both issues. Drawback is that we don't see if multiple drivers are trying to transfer while suspended. They need to be discovered one after the other now. This is better than a high CPU load because a really broken driver might try to resend endlessly. Link: https://bugs.archlinux.org/task/62391 Fixes: 275154155538 ("i2c: designware: Do not allow i2c_dw_xfer() calls while suspended") Signed-off-by: Wolfram Sang Reported-by: skidnik Acked-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Tested-by: skidnik Signed-off-by: Wolfram Sang

i2c: designware: Do not allow i2c_dw_xfer() calls while suspended

2019-02-23T10:08:48+00:00

On most Intel Bay- and Cherry-Trail systems the PMIC is connected over I2C and the PMIC is accessed through various means by the _PS0 and _PS3 ACPI methods (power on / off methods) of various devices. This leads to suspend/resume ordering problems where a device may be resumed and get its _PS0 method executed before the I2C controller is resumed. On Cherry Trail this leads to errors like these: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 But on Bay Trail this caused I2C reads to seem to succeed, but they end up returning wrong data, which ends up getting written back by the typical read-modify-write cycle done to turn on various power-resources. Debugging the problems caused by this silent data corruption is quite nasty. This commit adds a check which disallows i2c_dw_xfer() calls to happen until the controller's resume method has completed. Which turns the silent data corruption into getting these errors in dmesg instead: i2c_designware 80860F41:04: Error i2c_dw_xfer call while suspended ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.PCI0.GFX0._PS0, AE_ERROR Which is much better. Note the above errors are an example of issues which this patch will help to debug, the actual fix requires fixing the suspend order and this has been fixed by a different commit. Note the setting / clearing of the suspended flag in the suspend / resume methods is NOT protected by i2c_lock_bus(). This is intentional as these methods get called from i2c_dw_xfer() (through pm_runtime_get/put) a nd i2c_dw_xfer() is called with the i2c_bus_lock held, so otherwise we would deadlock. This means that there is a theoretical race between a non runtime suspend and the suspended check in i2c_dw_xfer(), this is not a problem since normally we should not hit the race and this check is primarily a debugging tool so hitting the check if there are suspend/resume ordering problems does not need to be 100% reliable. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang

Merge tag 'v4.19-rc7' into i2c/for-4.20

2018-10-11T21:07:30+00:00

This is the 4.19-rc7 release

i2c: designware: Set IRQF_NO_SUSPEND flag for all BYT and CHT controllers

2018-10-11T21:05:09+00:00

On some Cherry Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over a LPSS I2C controller. The GPU is a PCI device and PCI devices are powered-on at the resume_noirq resume phase. Since the GPU power-resources need the I2C controller, recent acpi_lpss.c changes now also power-up the LPSS I2C controllers on BYT and CHT devices in the resume_noirq resume phase. But during this phase the IRQ of the controller is disabled leading to these errors: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 This commit makes the i2c-designware controller set the IRQF_NO_SUSPEND flag when requesting the interrupt on BYT and CHT devices, so that the IRQ is left enabled during the noirq phase, fixing this. Tested-by: Jarkko Nikula Acked-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: designware: Call i2c_dw_clk_rate() only when calculating timings

2018-10-05T11:40:05+00:00

There are platforms which don't provide input clock rate but provide I2C timing parameters. Commit 3bd4f277274b ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") causes needless warning during probe on those platforms since i2c_dw_clk_rate(), which causes the warning when input clock is unknown, is called even when there is no need to calculate timing parameters. Fixes: 3bd4f277274b ("i2c: designware: Call i2c_dw_clk_rate() only once in i2c_dw_init_master()") Reported-by: Ard Biesheuvel Cc: # 4.19 Signed-off-by: Jarkko Nikula Tested-by: Ard Biesheuvel Signed-off-by: Wolfram Sang

i2c: designware: Remove Cherry Trail PMIC I2C bus pm_disabled workaround

2018-09-06T18:29:10+00:00

Commit a3d411fb38c0 ("i2c: designware: Disable pm for PMIC i2c-bus even if there is no _SEM method"), always set the pm_disabled flag on the I2C7 controller, even if its bus was not shared with the PUNIT. This was a workaround for various suspend/resume issues, after the following 2 commits this workaround is no longer necessary: Commit 541527728341 ("PM: i2c-designware-platdrv: Suspend/resume at the late/early stages") Commit e6ce0ce34f65 ("ACPI / LPSS: Add device link for CHT SD card dependency on I2C") Therefor this commit removes this workaround. After this commit the pm_disabled flag is only used to indicate that the bus is shared with the PUNIT and after other recent changes we no longer call dev_pm_syscore_device(dev, true), so we are no longer actually disabling (non-runtime) pm, so this commit also renames the flag to shared_with_punit to better reflect what it is for. Reviewed-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Hans de Goede Signed-off-by: Wolfram Sang

i2c: designware: Re-init controllers with pm_disabled set on resume

2018-08-30T21:02:13+00:00

On Bay Trail and Cherry Trail devices we set the pm_disabled flag for I2C busses which the OS shares with the PUNIT as these need special handling. Until now we called dev_pm_syscore_device(dev, true) for I2C controllers with this flag set to keep these I2C controllers always on. After commit 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation"), this no longer works. This commit modifies lpss_iosf_exit_d3_state() to only run if lpss_iosf_enter_d3_state() has ran before it, so that it does not run on a resume from hibernate (or from S3). On these systems the conditions for lpss_iosf_enter_d3_state() to run never become true, so lpss_iosf_exit_d3_state() never gets called and the 2 LPSS DMA controllers never get forced into D0 mode, instead they are left in their default automatic power-on when needed mode. The not forcing of D0 mode for the DMA controllers enables these systems to properly enter S0ix modes, which is a good thing. But after entering S0ix modes the I2C controller connected to the PMIC no longer works, leading to e.g. broken battery monitoring. The _PS3 method for this I2C controller looks like this: Method (_PS3, 0, NotSerialized) // _PS3: Power State 3 { If ((((PMID == 0x04) || (PMID == 0x05)) || (PMID == 0x06))) { Return (Zero) } PSAT |= 0x03 Local0 = PSAT /* \_SB_.I2C5.PSAT */ } Where PMID = 0x05, so we enter the Return (Zero) path on these systems. So even if we were to not call dev_pm_syscore_device(dev, true) the I2C controller will be left in D0 rather then be switched to D3. Yet on other Bay and Cherry Trail devices S0ix is not entered unless *all* I2C controllers are in D3 mode. This combined with the I2C controller no longer working now that we reach S0ix states on these systems leads to me believing that the PUNIT itself puts the I2C controller in D3 when all other conditions for entering S0ix states are true. Since now the I2C controller is put in D3 over a suspend/resume we must re-initialize it afterwards and that does indeed fix it no longer working. This commit implements this fix by: 1) Making the suspend_late callback a no-op if pm_disabled is set and making the resume_early callback skip the clock re-enable (since it now was not disabled) while still doing the necessary I2C controller re-init. 2) Removing the dev_pm_syscore_device(dev, true) call, so that the suspend and resume callbacks are actually called. Normally this would cause the ACPI pm code to call _PS3 putting the I2C controller in D3, wreaking havoc since it is shared with the PUNIT, but in this special case the _PS3 method is a no-op so we can safely allow a "fake" suspend / resume. Fixes: 12864ff8545f ("ACPI / LPSS: Avoid PM quirks on suspend and resume ...") Link: https://bugzilla.kernel.org/show_bug.cgi?id=200861 Cc: 4.15+ # 4.15+ Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang

i2c: designware: Add SPDX license tag

2018-08-20T08:45:45+00:00

Replace short statement in comment with proper SPDX license tag. Note, for i2c-desingware-slave.c the identifier is chosen in accordance with MODULE_LICENSE() macro since it is visible to user. Another point to this choice is that the header seems to be copy'n'paste from the other file of this very driver. Acked-by: Luis Oliveira Signed-off-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang