Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp2855775pxk; Mon, 28 Sep 2020 01:39:08 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzjNihRYCYXlEm6fYh9QIWdGu8FFdOzH8LabY1xb/dGvYVRVlsThfKAEyANBUG6pVi+4h6a X-Received: by 2002:a17:906:49cd:: with SMTP id w13mr571265ejv.151.1601282347993; Mon, 28 Sep 2020 01:39:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601282347; cv=none; d=google.com; s=arc-20160816; b=ohzxu74ISte6PxA0wN+L855R8gjlQj+mlA11FJ9paQ+QRD8W/+64gik7uR6RfpFwtg TyXN6MFJMideyEK9uXjtw/oz6mTKKNOzthnwHdaOz12VN/yaZjKZxgxBaIdpTcFDdrJn yxtFwmSHCyx2K+4/USW37KWi2EsWNgH3yK5J/WcbRxyP2tYkFlx0ztvVNrnqHjY8FN36 1f6uah+eFbEjNJFFpld+9PQoGmdMncaLgGCAmyFBbO+gh5X7TCRaN7FzmzM0E0gvbosw dWeGDvYrKByvTTXjaahBw8M5J0uQ1NfLs50/OmKPoi/fM5sIsXH8XnPVWh8YdJXJBSrx iuZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=E7u4TsW2NJDo5bYGnIM2L47jdWGrT2LbaqVw2AxoFQs=; b=Bd1GqLJsIXYAUW7r/BQGy3DCV0X4lEFS29chLzDBuGbjkXTQAFf6GcrTNp6yjC2Bmf dmWUIeGM7Udie3jQ9ja0BRNnj98pk5lh4C886tsPDYtVsvxMhPsgIWhrdNvBJWAMQZvy 3F0qE1JNjUeK40qUdk9tU9eAkppAl3hnbK7atvx0YbodHwgKgXGxqmhvV+hRUP9yNKgA DcbnB/zi8b/5oi9VTe3a4obUKb1aSluQ/kVBRd2asQZHnB1jXIezUoKm+RSE2iS/6HjN h1xEk4fTq5iovy9MHWZ/RUyBx9MQ29PaC+vnjB9oYQgnEcVL1a5bbuCrHcRNFIOSw7E/ 60Iw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n6si144227edy.596.2020.09.28.01.38.44; Mon, 28 Sep 2020 01:39:07 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726552AbgI1IgY (ORCPT + 99 others); Mon, 28 Sep 2020 04:36:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726826AbgI1IgX (ORCPT ); Mon, 28 Sep 2020 04:36:23 -0400 Received: from metis.ext.pengutronix.de (metis.ext.pengutronix.de [IPv6:2001:67c:670:201:290:27ff:fe1d:cc33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5F65AC0613D0 for ; Mon, 28 Sep 2020 01:36:23 -0700 (PDT) Received: from pty.hi.pengutronix.de ([2001:67c:670:100:1d::c5]) by metis.ext.pengutronix.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kModa-000084-2t; Mon, 28 Sep 2020 10:35:58 +0200 Received: from ukl by pty.hi.pengutronix.de with local (Exim 4.89) (envelope-from ) id 1kModO-0005Wh-8W; Mon, 28 Sep 2020 10:35:46 +0200 Date: Mon, 28 Sep 2020 10:35:46 +0200 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Jonathan =?utf-8?Q?Neusch=C3=A4fer?= Cc: Alexandre Belloni , Heiko Stuebner , devicetree@vger.kernel.org, Linus Walleij , Thierry Reding , Sam Ravnborg , linux-rtc@vger.kernel.org, Arnd Bergmann , Mauro Carvalho Chehab , Fabio Estevam , Daniel Palmer , Andy Shevchenko , Andreas Kemnade , NXP Linux Team , linux-pwm@vger.kernel.org, Stephan Gerhold , allen , Sascha Hauer , Lubomir Rintel , Rob Herring , Lee Jones , linux-arm-kernel@lists.infradead.org, Alessandro Zummo , linux-kernel@vger.kernel.org, Mark Brown , Pengutronix Kernel Team , Heiko Stuebner , Josua Mayer , Shawn Guo , "David S. Miller" Subject: Re: [PATCH v3 4/7] pwm: ntxec: Add driver for PWM function in Netronix EC Message-ID: <20200928083546.gwu7ucx7os5yc5bn@pengutronix.de> References: <20200924192455.2484005-1-j.neuschaefer@gmx.net> <20200924192455.2484005-5-j.neuschaefer@gmx.net> <20200925063037.fcrmqvpe5noi3ef4@pengutronix.de> <20200927211044.GC2510@latitude> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ydya4zilwk3y3dfw" Content-Disposition: inline In-Reply-To: <20200927211044.GC2510@latitude> X-SA-Exim-Connect-IP: 2001:67c:670:100:1d::c5 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --ydya4zilwk3y3dfw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jonathan, On Sun, Sep 27, 2020 at 11:10:44PM +0200, Jonathan Neusch=E4fer wrote: > On Fri, Sep 25, 2020 at 08:30:37AM +0200, Uwe Kleine-K=F6nig wrote: > > > + if (period > MAX_PERIOD_NS) { > > > + dev_warn(pwm->dev, > > > + "Period is not representable in 16 bits after division by %u: %u= \n", > > > + TIME_BASE_NS, period); > >=20 > > No error messages in .apply() please; this might spam the kernel log. > > > > Also the expectation when a too big period is requested is to configure > > for the biggest possible period. So just do: > >=20 > > if (period > MAX_PERIOD_NS) { > > period =3D MAX_PERIOD_NS; > >=20 > > if (duty > period) > > duty =3D period; > > } > >=20 > > (or something equivalent). >=20 > Okay, I'll adjust it. >=20 > > > + /* > > > + * Writing a duty cycle of zone puts the device into a state where > >=20 > > What is "zone"? A mixture of zero and one and so approximately 0.5? >=20 > Oops, that's a typo. I just meant "zero". >=20 > > > + * writing a higher duty cycle doesn't result in the brightness tha= t it > > > + * usually results in. This can be fixed by cycling the ENABLE regi= ster. > > > + * > > > + * As a workaround, write ENABLE=3D0 when the duty cycle is zero. > > > + */ > > > + if (state->enabled && duty !=3D 0) { > > > + res =3D regmap_write(pwm->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8= (1)); > > > + if (res) > > > + return res; > > > + > > > + /* Disable the auto-off timer */ > > > + res =3D regmap_write(pwm->ec->regmap, NTXEC_REG_AUTO_OFF_HI, ntxec= _reg8(0xff)); > > > + if (res) > > > + return res; > > > + > > > + return regmap_write(pwm->ec->regmap, NTXEC_REG_AUTO_OFF_LO, ntxec_= reg8(0xff)); > > > + } else { > > > + return regmap_write(pwm->ec->regmap, NTXEC_REG_ENABLE, ntxec_reg8(= 0)); > > > + } > >=20 > > This code is wrong for state->enabled =3D false. >=20 > Why? Hm, I wonder the same. Probably I just misunderstood the code, sorry :-\ > > How does the PWM behave when .apply is called? Does it complete the > > currently running period? Can it happen that when you switch from say > >=20 > > .duty_cycle =3D 900 * TIME_BASE_NS (0x384) > > .period =3D 1800 * TIME_BASE_NS (0x708) > >=20 > > to > >=20 > > .duty_cycle =3D 300 * TIME_BASE_NS (0x12c) > > .period =3D 600 * TIME_BASE_NS (0x258) > >=20 > > that a period with > >=20 > > .duty_cycle =3D 388 * TIME_BASE_NS (0x184) > > .period =3D 1800 * TIME_BASE_NS (0x708) > > =09 > > (because only NTXEC_REG_PERIOD_HIGH was written when the new period > > started) or something similar is emitted? >=20 > Changes take effect after the low byte is written, so a result like 0x184 > in the above example should not happen. >=20 > When the period and duty cycle are both changed, it temporarily results > in an inconsistent state: >=20 > - period =3D 1800ns, duty cycle =3D 900ns > - period =3D 600ns, duty cycle =3D 900ns (!) > - period =3D 600ns, duty cycle =3D 300ns Does this always happen, or only if a new cycle starts at an unlucky moment? > The inconsistent state of duty cycle > period is handled gracefully by > the EC and it outputs a 100% duty cycle, as far as I can tell. OK. > I currently don't have a logic analyzer / oscilloscope to measure > whether we get full PWM periods, or some kind of glitch when the new > period starts in the middle of the last one. You can even check this with an LED using something like: pwm_apply(mypwm, {.enabled =3D true, .duty_cycle =3D $big, .period =3D $bi= g}); pwm_apply(mypwm, {.enabled =3D false, ... }); =2E If the period is completed the LED is on for $big ns, if not the LED is on for a timespan that is probably hardly noticable with the human eye. > > > +} > > > + > > > +static struct pwm_ops ntxec_pwm_ops =3D { > > > + .apply =3D ntxec_pwm_apply, > >=20 > > Please implement a .get_state() callback. And enable PWM_DEBUG during > > your tests. >=20 > The device doesn't support reading back the PWM state. What should a > driver do in this case? Document it as a limitation, please. Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --ydya4zilwk3y3dfw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEfnIqFpAYrP8+dKQLwfwUeK3K7AkFAl9xoF8ACgkQwfwUeK3K 7Am4PAf/d6jJ0rLJJBKslZzKA1ulRj6vzQKAWN3OQRe0DAiKrHOk9rREZywu8qab ij5usrKGU9lnrCsUDqOskvJW8F9zTfl9R9stEmw6yFvXsx/PbcsJ7u5zQtdTwlgu o5VSEJr9Ym/lRzeptOLVUnrO0s4DmLQEkf9Xe/9buxLDg97sFVeyurLLiHyblf7M YzROKhF66NGleiw41Xe0NNeM3iEPwV8FoDUYYQSWiwG9B3ENVGEpp2jnvPArUC1x E90X9u6xKIk2bxbmcE8pd+bDtdWpuL1DIyI4NjyePdN1JHcGsyJwNsg4dcY1uV8e h+t4gHpfpZPaA+us9ukQsDxpX0iUxA== =xFyB -----END PGP SIGNATURE----- --ydya4zilwk3y3dfw--