Re: [PATCH] i2c: rcar: Fix clients using i2c from suspend callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jan 22, 2019 at 11:03:57AM +0100, Geert Uytterhoeven wrote:

[...]

> On second resume, the sound driver fails with:
> 
>     cs2000-cp 2-004f: pll lock failed
>     rcar_sound ec500000.sound: can't use clk 1
> 
> As the CS2000 clock driver needs to send I2C messages during suspend,
> the I2C controller driver should be suspended later, and resumed
> earlier.  Fix this by using the noirq sleep ops instead of the normal
> sleep ops, which are called after the late sleep ops, as used by the
> CS2000 clock driver.
> 
> Fixes: 18569fa89a4db9ed ("i2c: rcar: add suspend/resume support")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@xxxxxxxxx>
> ---
> The various I2C drivers seem to use a mix of normal, late, and noirq
> sleep ops.
> 
> For this particular use case, both the late and noirq sleep ops work,
> but that may depend on link order.
> 
> Given the comment about wake-up sources in commit 57186fe3db3ec462
> ("i2c: exynos5: Properly use the "noirq" variants of suspend/resume"),
> perhaps all of them should use SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() instead?

Likely.

My plan is to first deal with the issues how to do I2C when irqs are
already disabled. Once this is in place as an exception for justified
cases, I think we can deal with the other devices; so every special user
gets the proper treatment and we are still able to WARN about devices
doing I2C transfers when they shouldn't do it.

All that being said:

Applied to for-next, thanks!

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux