From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_NEOMUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71E52C43441 for ; Sun, 18 Nov 2018 11:30:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 38DB12080F for ; Sun, 18 Nov 2018 11:30:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38DB12080F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727295AbeKRVuv (ORCPT ); Sun, 18 Nov 2018 16:50:51 -0500 Received: from metis.ext.pengutronix.de ([85.220.165.71]:45227 "EHLO metis.ext.pengutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726077AbeKRVuv (ORCPT ); Sun, 18 Nov 2018 16:50:51 -0500 Received: from ptx.hi.pengutronix.de ([2001:67c:670:100:1d::c0]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gOLHk-0004nJ-40; Sun, 18 Nov 2018 12:30:40 +0100 Received: from ukl by ptx.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1gOLHe-0007sW-KP; Sun, 18 Nov 2018 12:30:34 +0100 Date: Sun, 18 Nov 2018 12:30:34 +0100 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= To: Lothar =?iso-8859-1?Q?Wa=DFmann?= Cc: Thierry Reding , =?utf-8?B?Vm9rw6HEjQ==?= Michal , Mark Rutland , "devicetree@vger.kernel.org" , "linux-pwm@vger.kernel.org" , Lukasz Majewski , "linux-kernel@vger.kernel.org" , Rob Herring , "kernel@pengutronix.de" , Fabio Estevam , Linus Walleij Subject: Re: [RCF PATCH,v2,2/2] pwm: imx: Configure output to GPIO in disabled state Message-ID: <20181118113034.pguv66idde5idinb@pengutronix.de> References: <20181108191855.zuon3ecv4yjfbs7g@pengutronix.de> <283cfef3-16d0-8bd4-e306-6e34d44c3a86@ysoft.com> <20181109165555.vqbiwh4hlcnozdna@pengutronix.de> <20181114113449.GB2620@ulmo> <20181114215120.vddykljqyavm64wj@pengutronix.de> <20181115152545.GA8611@ulmo> <20181115203733.qvonika6yhn2bsnb@pengutronix.de> <20181116095124.GA28631@ulmo> <20181116103929.cxfvuc2te7cadhp2@pengutronix.de> <20181116125633.4e110125@ipc1.ka-ro> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20181116125633.4e110125@ipc1.ka-ro> User-Agent: NeoMutt/20170113 (1.7.2) X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c0 X-SA-Exim-Mail-From: ukl@pengutronix.de X-SA-Exim-Scanned: No (on metis.ext.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Lothar, On Fri, Nov 16, 2018 at 12:56:33PM +0100, Lothar Waßmann wrote: > Uwe Kleine-König wrote: > > On Fri, Nov 16, 2018 at 10:51:24AM +0100, Thierry Reding wrote: > > > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote: > > > > On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote: > [...] > > > But why? The backlight doesn't care about the specific pinmuxing of the > > > PWM pin. All it cares about is the PWM signal. That's the level of > > > abstraction that the PWM consumer expects, anything lower level belongs > > > in the PWM driver. > > > > The backlight driver cares about the PWM pin muxing because if it's > > wrongly muxed the backlight doesn't work as intended. > > With this argumentation you would also have to define the clocks needed > for the PWM in the backlight (or whatever pwm consumer) driver, because > if the clocks are not set up correctly the backlight won't work as > expected... The reason why I think it is sensible to put the PWM pin into the consumer's pinctrl is that only after the consumer grabbed the PWM it is fixed (in software) what the idle level is. So the pwm alone isn't complete and it's not clear what to do with this pin. High-Z is probably a good choice for most setups, but this relies on a PU or PD into the right direction that isn't always present. (I'm currently working with such a machine, where such a PD/PU is missing. Not entirely sure this is a problem because maybe the display unit has a pull. Didn't take the time yet to verify.) Also this needs some care because the PWM might already running on purpose (e.g. to show a splash screen) then switching to High-Z should be avoided. So IMHO it is sensible to delay setting up the pinmux until the boundary conditions are fixed. This is also the general idea with the involvement of pinctrl stuff, but given that even without handling pinctrl specially it already works just fine when the pwm is only muxed as part of the consumer. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |