Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753077Ab3FDJvf (ORCPT ); Tue, 4 Jun 2013 05:51:35 -0400 Received: from arroyo.ext.ti.com ([192.94.94.40]:54071 "EHLO arroyo.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751235Ab3FDJvd convert rfc822-to-8bit (ORCPT ); Tue, 4 Jun 2013 05:51:33 -0400 From: "Hebbar, Gururaja" To: Kevin Hilman CC: "grant.likely@linaro.org" , "linus.walleij@linaro.org" , "rob.herring@calxeda.com" , "davinci-linux-open-source@linux.davincidsp.com" , "devicetree-discuss@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" , "linux@arm.linux.org.uk" , "linux-kernel@vger.kernel.org" , "Bedia, Vaibhav" , "Rajashekhara, Sudhakar" , Tony Lindgren , Wolfram Sang , "linux-omap@vger.kernel.org" , "linux-i2c@vger.kernel.org" , Linus Walleij Subject: RE: [PATCH 11/11] i2c: omap: enhance pinctrl support Thread-Topic: [PATCH 11/11] i2c: omap: enhance pinctrl support Thread-Index: AQHOXimmVxfgXGT07Eyasoe5jzaNzZklVYTg Date: Tue, 4 Jun 2013 09:50:49 +0000 Message-ID: <1BAFE6F6C881BF42822005164F1491C33EC22349@DBDE04.ent.ti.com> References: <1369995191-20855-1-git-send-email-gururaja.hebbar@ti.com> <1369995191-20855-12-git-send-email-gururaja.hebbar@ti.com> <87bo7r10s9.fsf@linaro.org> In-Reply-To: <87bo7r10s9.fsf@linaro.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.170.142] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2861 Lines: 77 On Fri, May 31, 2013 at 23:37:02, Kevin Hilman wrote: > +Linus Walleij (pinctrl maintainer) > > Hebbar Gururaja writes: > > > Amend the I2C omap pin controller to optionally take a pin control > > handle and set the state of the pins to: > > > > - "default" on boot, resume and before performing an i2c transfer > > - "idle" after initial default, after resume default, and after each > > i2c xfer > > - "sleep" on suspend() > > > > By optionally putting the pins into sleep state in the suspend callback > > we can accomplish two things. > > - One is to minimize current leakage from pins and thus save power, > > - second, we can prevent the IP from driving pins output in an > > uncontrolled manner, which may happen if the power domain drops the > > domain regulator. > > > > Note: > > A .suspend & .resume callback is added which simply puts the pins to sleep > > state upon suspend & are moved to default & idle state upon resume. > > > > If any of the above pin states are missing in dt, a warning message > > about the missing state is displayed. > > If certain pin-states are not available, to remove this warning message > > pass respective state name with null phandler. > > > > (Changes based on i2c-nomadik.c) > > > > Signed-off-by: Hebbar Gururaja > > Cc: Tony Lindgren > > Cc: Wolfram Sang > > Cc: linux-omap@vger.kernel.org > > Cc: linux-i2c@vger.kernel.org > > [...] > > > @@ -1123,14 +1138,47 @@ omap_i2c_probe(struct platform_device *pdev) > > dev->set_mpu_wkup_lat = pdata->set_mpu_wkup_lat; > > } > > > > - dev->pins = devm_pinctrl_get_select_default(&pdev->dev); > > - if (IS_ERR(dev->pins)) { > > - if (PTR_ERR(dev->pins) == -EPROBE_DEFER) > > + dev->pinctrl = devm_pinctrl_get(&pdev->dev); > > + if (!IS_ERR(dev->pinctrl)) { > > + dev->pins_default = pinctrl_lookup_state(dev->pinctrl, > > + PINCTRL_STATE_DEFAULT); > > This part is already done by probe in driver core, why does it need to > be done again. dev->pins->default_state should already have this. > (c.f. pinctrl_bind_pins() in drivers/base/pinctrl.c) > > But that brings up a bigger question about whether or not we should be > doing the rest of this (idle/sleep) pin management in the drivers or in > the driver core as well. I would much prefer it be handled by the > driver core. > > In fact, since these are all PM related events, it should probably be > handled by the PM core and seems pretty straight forward to do so. Let me pull out some info about these and come back > > Kevin > Regards, Gururaja -- 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/