Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753700AbaFWXb0 (ORCPT ); Mon, 23 Jun 2014 19:31:26 -0400 Received: from mail-pb0-f51.google.com ([209.85.160.51]:40721 "EHLO mail-pb0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752260AbaFWXbX (ORCPT ); Mon, 23 Jun 2014 19:31:23 -0400 From: Kevin Hilman To: Doug Anderson Cc: Wolfram Sang , Kukjin Kim , Tomasz Figa , Javier Martinez Canillas , naveen krishna , Jingoo Han , Jean Delvare , Simon Glass , Paul Gortmaker , Masanari Iida , Sachin Kamat , "linux-i2c\@vger.kernel.org" , "linux-arm-kernel\@lists.infradead.org" , linux-samsung-soc , "linux-kernel\@vger.kernel.org" Subject: Re: [PATCH] i2c: exynos5: Properly use the "noirq" variants of suspend/resume References: <1403155273-1057-1-git-send-email-dianders@chromium.org> <7h8uosyc3k.fsf@paris.lan> <7hwqcbs166.fsf@paris.lan> <7h7g4brx6w.fsf@paris.lan> <7h38evp8ng.fsf@paris.lan> Date: Mon, 23 Jun 2014 16:31:21 -0700 In-Reply-To: (Doug Anderson's message of "Mon, 23 Jun 2014 15:42:01 -0700") Message-ID: <7hwqc7nqye.fsf@paris.lan> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Doug Anderson writes: > Kevin, > > On Mon, Jun 23, 2014 at 3:23 PM, Kevin Hilman 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/