From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754847AbcAMTkj (ORCPT ); Wed, 13 Jan 2016 14:40:39 -0500 Received: from muru.com ([72.249.23.125]:55180 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbcAMTkh (ORCPT ); Wed, 13 Jan 2016 14:40:37 -0500 Date: Wed, 13 Jan 2016 11:40:32 -0800 From: Tony Lindgren To: Nishanth Menon Cc: "H. Nikolaus Schaller" , Grygorii Strashko , Laxman Dewangan , =?utf-8?Q?Beno=C3=AEt?= Cousson , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Russell King , linux-omap , devicetree@vger.kernel.org, LKML , Marek Belisko , =?utf-8?Q?Gra=C5=BEvydas?= Ignotas , Keerthy Subject: Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery Message-ID: <20160113194032.GL12777@atomide.com> References: <001346CD-CF31-4FEF-B406-B89EEBDFA063@goldelico.com> <56966558.1070608@ti.com> <569669C5.2070200@ti.com> <20160113164856.GF12777@atomide.com> <5696896F.4090309@ti.com> <20160113180006.GJ12777@atomide.com> <2B99611A-5D2E-4D17-A17D-0150516109FD@goldelico.com> <56969800.5010206@ti.com> <5696A002.6050402@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5696A002.6050402@ti.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Nishanth Menon [160113 11:06]: > On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote: > > > > Am 13.01.2016 um 19:31 schrieb Nishanth Menon : > > > >> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote: > >>> Since the scratchpad is not used we can permanently enable msecure. Which > >>> means that we must somehow get the driving output to be "1". > >>> > >>> This can be either done by > >>> * a gpio with pull-up - switched to input mode as I proposed, or > >> > >> I think you intended to suggest to do a mux to gpio with just pinmux > >> pull? > > > > Yes. > > > >> The internal pull on padconf is very weak > >> - for typical needs like > >> these, it is rather suggested to stick with real GPIO drive to prevent > >> conditions like noise interference(for example). > > > > > > well, on OMAP5 pull up/down are astonishingly strong :) > > 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic. > > So a noise source must be coupled by an impedance in the 1 kOhm range. > > This is quite rare. So I would not worry about that. > > > > Interesting. I did not know that, and have'nt dug at people to confirm > that either :). > > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) > and are good for avoiding higher leakage due to floating input level, > and may not be sufficient for valid logic 1/0 depending on what else is > connected on the board. If a signal must absolutely be pulled to a > valid logic 1 or 0 for system functionality, then an external pull > should be used." > > Anyways... will let Tony decide where he wants to go on this.. Eek now we have at least three options! Time for online vote: 1. Use msecure pinmux and let whatever mystery software control the pin completely out of our control like we've been doing with the mainline kernel for years. 2. Set up the msecure pin as GPIO output high unconditionally. This is what the TI android kernel tree seems to be doing. 3. New suggestion to use the SoC internal pull to keep the msecure pin high. This might be a little bit more power friendly than option #2 or #3. Maybe option #3 would save a little bit more power compared to options 1 and 2? Anyways, considering what's been discussed, after the minimal RTC fix we could also add code to allow the TWL driver optionally configure the GPIO. This way the TWL driver could also check the GPIO state in case some out-of-our-control mystery software goes tweak the msecure pin state. Or the RTC driver could just check that the bits really change after= writing them. Then we would at least know things are not working right for the TWL related RTC drivers. Regards, Tony