Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753529AbdDMMOe (ORCPT ); Thu, 13 Apr 2017 08:14:34 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:35260 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753448AbdDMMOc (ORCPT ); Thu, 13 Apr 2017 08:14:32 -0400 MIME-Version: 1.0 In-Reply-To: <20170413091513.GA1878@localhost.localdomain> References: <1491568725-14882-1-git-send-email-ckeepax@opensource.wolfsonmicro.com> <20170410201758.lobmtzxt2jgcwwvc@rob-hp-laptop> <1491903267.4826.8.camel@rf-debian.wolfsonmicro.main> <20170413091513.GA1878@localhost.localdomain> From: Linus Walleij Date: Thu, 13 Apr 2017 14:14:25 +0200 Message-ID: Subject: Re: [PATCH 1/2] mfd: arizona: Add GPIO maintain state flag To: Charles Keepax Cc: Richard Fitzgerald , Rob Herring , Lee Jones , Alexandre Courbot , Mark Rutland , "linux-gpio@vger.kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "open list:WOLFSON MICROELECTRONICS DRIVERS" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 991 Lines: 24 On Thu, Apr 13, 2017 at 11:15 AM, Charles Keepax wrote: > On Tue, Apr 11, 2017 at 10:34:27AM +0100, Richard Fitzgerald wrote: >> 3) The codec only has to be kept awake while any such GPIO is actually >> in use. See (2) > > Yeah option 3 is the primary issue here, we only want to keep the > CODEC enabled whilst specific GPIOs are in use. As GPIOs can be > dynamically requested/released by things in the kernel we want to > know which GPIOs require the CODEC to be kept alive. Also in the > future one might be tempted to add maintain whilst high and > maintain whilst low options for lines with pulls on them to > further optimise power. Why does this have to be encoded as information in the device tree? Isn't it better to use a static table in the driver? I don't see what use system integrators and others playing around with the device tree has of this, it will just be confusing to them if it is a chip-internal detail. Yours, Linus Walleij