Messages in this thread | | | From | Kevin Hilman <> | Subject | Re: [PATCH] i2c: exynos5: Properly use the "noirq" variants of suspend/resume | Date | Mon, 23 Jun 2014 16:31:21 -0700 |
| |
Doug Anderson <dianders@chromium.org> writes:
> Kevin, > > On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote: >>> So I guess in this case the truly correct way to handle it is: >>> >>> 1. i2c controller should have Runtime PM even though (as per the code >>> now) there's nothing you can do to it to save power under normal >>> circumstances. So the runtime "suspend" code would be a no-op. >>> >>> 2. When the i2c controller is told to runtime resume, it should >>> double-check if a full SoC poweroff has happened since the last time >>> it checked. In this case it should reinit its hardware. >>> >>> 3. If the i2c controller gets a full "resume" callback then it should >>> also reinit the hardware just so it's not sitting in a half-configured >>> state until the first peripheral uses it. >>> >>> If later someone finds a way to power gate the i2c controller when no >>> active transfers are going (and we actually save non-trivial power >>> doing this) then we've got a nice place to put that code. >>> >>> NOTE: Unless we can actually save power by power gating the i2c >>> peripheral when there are no active transfers, we would also just have >>> the i2c_xfer() init the hardware if needed. Maybe that's kinda gross, >>> though. >> >> Yes, this is how we manage the i2c controller on OMAP. >> >> Essentially, between every xfer, the hw is disabled and can potentially >> lose context, so eveery xfer requires a hw init. We use the runtime PM >> "autosuspend" feature so that it stays alive for X milliseconds so >> bursty i2c xfers are not punished. >> >> Have a look at drivers/i2c/busses/i2c-omap.c. >> >> You'll notice there are not callbacks for system suspend/resume, it's >> only doing runtime PM. > > OK, cool! That might be a bit too aggressive of a change for what I > can take on right now. I've filed http://crbug.com/388007 to see if > Samsung can take a look at this.
Sure. While I think moving to runtime PM is the right thing to do, that alone shouldn't block this patch.
Kevin
| |