Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752888AbaFWWmG (ORCPT ); Mon, 23 Jun 2014 18:42:06 -0400 Received: from mail-vc0-f172.google.com ([209.85.220.172]:37942 "EHLO mail-vc0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752260AbaFWWmD (ORCPT ); Mon, 23 Jun 2014 18:42:03 -0400 MIME-Version: 1.0 In-Reply-To: <7h38evp8ng.fsf@paris.lan> 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 15:42:01 -0700 X-Google-Sender-Auth: MahCuVkw74j7EVb1yyiVC5mKGVQ Message-ID: Subject: Re: [PATCH] i2c: exynos5: Properly use the "noirq" variants of suspend/resume From: Doug Anderson To: Kevin Hilman 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" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -Doug -- 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/