Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp470338imm; Wed, 22 Aug 2018 07:21:15 -0700 (PDT) X-Google-Smtp-Source: AA+uWPzmwalDUl9XnwKJd1aRXYxmTQfpiUi58Nqr0M5/LiF7M+VL7W+jJ8FIXlDi7jRK5PNuxn8o X-Received: by 2002:a17:902:a60a:: with SMTP id u10-v6mr13349086plq.104.1534947675129; Wed, 22 Aug 2018 07:21:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534947675; cv=none; d=google.com; s=arc-20160816; b=l4rMWf72ZoegiprKLlh3OWlVeaVxd+Dnr7MljluzUDkKl4fpqp/pMblZuK5JZJ2pkW JiOe4dSXg8iDgy0x/gW73wcjCOsezKNIChujglsO6p3tWL/KW6iNgYYXb5h/Y9YQLUlM z/0JOXnNo61Ukb6rGW5k2S2fftoQSumGQnsTCMuMz1jeVSHbYXz94QJjPUbN9KbJmeGs zFENfKaer0EoVnWFbAlf3i91YYMlFjw+4k1g+2j5CPKWt+9IqAqCMWNh0qmYUz2GStrP lDYDfmtX1hupl6B+5MRAQBMYNiehy0vHWZRHZxCQ4G6nN5obFfQBl9h8Lwo7ZcTn98iq kpCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=wr+kptxEPXTPGAjwUa6KCrZjCvtTYG5WB2i+ZnjT4ZQ=; b=P7BJ9be9IAHO31UfEWJgWw3lQM94QxrHI5R1XneFwSfGe9lLfY/zTl9fDNWHkpqnrY jk8FPKXRHqVlVRoBtsyo7Ey1kTKZCubLx5g5juHM0nn5y3C2ZWRc23VMBdE9Kw8dAxaE RE3tLrm5xXfZcmxc34j3E7cvAktRhtIMiGv6EncAmXzzA3D6oasyvEV0WlsEKWLTn15s 7K7+56IFLY9uhm1O24+EUNH7FF5GK+KLB1vlhrqCzEkhBqxHfPGcQziBDAnnutfXr//O /aldIfBRhpLNFY+oBMouOrTR26ALvGDOrk/a+KXoJSJWffo/Hry6AuGfLbj38SBJHiHI bKOg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h69-v6si1792544pge.13.2018.08.22.07.21.00; Wed, 22 Aug 2018 07:21:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729218AbeHVRfr convert rfc822-to-8bit (ORCPT + 99 others); Wed, 22 Aug 2018 13:35:47 -0400 Received: from smtprelay03.ispgateway.de ([80.67.31.41]:62245 "EHLO smtprelay03.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728197AbeHVRfq (ORCPT ); Wed, 22 Aug 2018 13:35:46 -0400 X-Greylist: delayed 10395 seconds by postgrey-1.27 at vger.kernel.org; Wed, 22 Aug 2018 13:35:45 EDT Received: from [89.1.81.74] (helo=ipc1.ka-ro) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fsTqH-0002eU-Lh; Wed, 22 Aug 2018 16:10:37 +0200 Date: Wed, 22 Aug 2018 16:10:36 +0200 From: Lothar =?UTF-8?B?V2HDn21hbm4=?= To: Michal =?UTF-8?B?Vm9rw6HEjQ==?= Cc: Thierry Reding , Rob Herring , Mark Rutland , devicetree@vger.kernel.org, linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org, Lukasz Majewski , Fabio Estevam Subject: Re: [RFC PATCH 1/2] dt-bindings: pwm: imx: Allow switching PWM output between PWM and GPIO Message-ID: <20180822161036.4d69bdc1@ipc1.ka-ro> In-Reply-To: <18b4a847-bc59-4450-331a-0b17f27c97a8@ysoft.com> References: <1534862333-27950-1-git-send-email-michal.vokac@ysoft.com> <1534862333-27950-2-git-send-email-michal.vokac@ysoft.com> <20180822081436.13d8f55b@ipc1.ka-ro> <175003bc-eae7-1b30-ebfe-b56ffc58705e@ysoft.com> <20180822131758.162d5351@ipc1.ka-ro> <18b4a847-bc59-4450-331a-0b17f27c97a8@ysoft.com> Organization: Ka-Ro electronics GmbH MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Df-Sender: bHdAa2Fyby1lbGVjdHJvbmljcy5kZQ== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Vokáč wrote: > On 22.8.2018 13:17, Lothar Waßmann wrote: > > Michal Vokáč wrote: > > > >> On 22.8.2018 08:14, Lothar Waßmann wrote: > >>> Michal Vokáč wrote: > >>> > >>>> Output of the PWM block of i.MX SoCs is always zero volts when the block > >>>> is disabled. This can caue issues when inverted PWM polarity is needed. > >>>> With inverted polarity a duty cycle = 0% corresponds to solid high level > >>>> on the output. If the PWM is dissabled its output instantly goes to solid > >>>> zero which corresponds to duty cycle = 100%. > >>>> > >>>> To have a trully inverted PWM output configure the PWM pad as a GPIO > >>>> with pull-up. Then switch the pad to PWM output whenever non-zero > >>>> duty cycle is needed. > >>>> > >>>> Signed-off-by: Michal Vokáč > >>>> --- > >>>> Documentation/devicetree/bindings/pwm/imx-pwm.txt | 44 +++++++++++++++++++++++ > >>>> 1 file changed, 44 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt > >>>> index c61bdf8..3b1bc4c 100644 > >>>> --- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt > >>>> +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt > >>>> @@ -14,6 +14,12 @@ See the clock consumer binding, > >>>> Documentation/devicetree/bindings/clock/clock-bindings.txt > >>>> - interrupts: The interrupt for the pwm controller > >>>> > >>>> +Optional properties: > >>>> +- pinctrl: For i.MX27 and newer SoCs. Add extra pinctrl to configure the PWM > >>>> + pin to gpio function. It allows control over the pin output level when the > >>>> + PWM block is disabled. This is meant to be used if inverted polarity of the > >>>> + PWM signal is required. See "Inverted PWM output" section bellow. > >>>> + > >>>> Example: > >>>> > >>>> pwm1: pwm@53fb4000 { > >>>> @@ -25,3 +31,41 @@ pwm1: pwm@53fb4000 { > >>>> clock-names = "ipg", "per"; > >>>> interrupts = <61>; > >>>> }; > >>>> + > >>>> +Inverted PWM output > >>>> +------------------- > >>>> + > >>>> +The i.MX SoC has such limitation that whenever a pad is configured as a PWM > >>>> +output, the output level is always zero volts when the PWM block is disabled. > >>>> +The zero output level is actively driven by the output stage of the PWM block > >>>> +and can not be overridden by pull-up. It also does not matter what PWM polarity > >>>> +a PWM client (e.g. backlight) requested. > >>>> + > >>>> +To gain control of the PWM output level in disabled state two pinctrl states > >>>> +can be used. The "default" state and the "pwm" state. In the default state the > >>>> > >>> The "default" function of a PWM is to deliver a PWM signal. So it is > >>> more sensible to me to have the PWM function as "default" and a "gpio" > >>> function as alternative state. > >> > >> Yes, I totally agree that using "default" for PWM and "gpio" as the > >> alternative function seems more sensible. That is actually how I started. > >> Then I realized that that way you end up with the PWM pad set to zero > >> until the first call of imx_pwm_apply_v2 where you can select the GPIO > >> function. On my system that first call is made by pwm-backlight more than > >> 3s after pinctrl init. > >> > >> I suggested to use the "default" state as a GPIO function as the only way > >> how to get a truly inverted PWM output all the time from power-up to > >> power-down. > >> > >> In my opinion it is up to the DT author what pad configuration he uses for > >> each pinctrl function as he knows what the HW really needs. I see that this > >> approach is kind of controversial but I hope that with good documentation > >> this would not be a problem. And as I wrote in the intro, it is absolutely > >> optional. If you do not need it, you do not use it. > >> > > This is OK so far. > > But the approach with the pin being driven high via the pullup > > configuration has a fundamental flaw: > > The pwm polarity is specified by the PWM client (e.g: the pwm-backlight > > driver: > > pwms = <&pwm0 0 PWM_POLARITY_INVERTED>; > > ) > > The pinconfig is defined in the pinctrl of the PWM driver. > > > > If you have clients that may use the same PWM instance and require > > different polarity, there is no way to set the pullup/-down > > configuration in accordance with the clients needs. > > Hmm, I did not think about more than one PWM client. Is it even possible > to design such board? Do you have an example of such usage? It would mean > My use case is attaching different displays to the same baseboard, where some displays have the brightness control pin inverted with respect to the others. It's easy to change the compatible string for the simple-panel driver and the PWM polarity setting for the pwm-backlight driver from U-Boot according to the display model, but it's not so easy, to edit the pinctrl settings from pull-up to pull-down or vice versa. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@karo-electronics.de ___________________________________________________________