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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B1E84C6FD1C for ; Sat, 25 Mar 2023 08:20:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=DCdc4gltfsigzX7EYrDyssrdGL9ogd8saEUhPHcJ1MM=; b=SoyrvPcImALNLQUAj920zsP3RQ RKRqFtLNh0cZ4FOHMQi2WcQfEPRVxPhkEji96Lz2m+SumZDV7yhV3DyNTrF2KP4yUCZnOKWV5thMF MZs7ZzKUMKOkBGrGgGZMvd09rlCEN9SpZ69UhzrZB49qxi4KbeaaI5aEJHKEqTZIgXb30yQb84Fys 1evJOXhcJcc/QUsEDIDo4GpZuxFVWGQxCXJUIN37EyEfExHKVSahjBiyNSzr/cLf+YjKW9v9pfD4T NnJkAUcBEZ3MXiy8jdlB9b70/6MzSZArmfT45C+8BQn5sOv9cDLm/dhNmp2cClhtcEZRKatg8hjhY PPr4mTtA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pfz8O-006RQQ-01; Sat, 25 Mar 2023 08:20:20 +0000 Received: from metis.ext.pengutronix.de ([2001:67c:670:201:290:27ff:fe1d:cc33]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pfz8J-006RP8-11 for linux-amlogic@lists.infradead.org; Sat, 25 Mar 2023 08:20:17 +0000 Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.ext.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pfz8A-0005n5-VZ; Sat, 25 Mar 2023 09:20:07 +0100 Received: from [2a0a:edc0:0:900:1d::77] (helo=ptz.office.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtp (Exim 4.94.2) (envelope-from ) id 1pfz8A-006ZY1-AM; Sat, 25 Mar 2023 09:20:06 +0100 Received: from ukl by ptz.office.stw.pengutronix.de with local (Exim 4.94.2) (envelope-from ) id 1pfz89-007phI-Fs; Sat, 25 Mar 2023 09:20:05 +0100 Date: Sat, 25 Mar 2023 09:20:04 +0100 From: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= To: Heiner Kallweit Cc: "thierry.reding@gmail.com" , Neil Armstrong , Kevin Hilman , Jerome Brunet , Martin Blumenstingl , linux-pwm@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" , "open list:ARM/Amlogic Meson..." Subject: Re: [PATCH] pwm: meson: add support for S4 chip family Message-ID: <20230325082004.q7suqrt2udzgq4mb@pengutronix.de> References: MIME-Version: 1.0 In-Reply-To: X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 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-amlogic@lists.infradead.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230325_012015_360239_D50D465F X-CRM114-Status: GOOD ( 34.34 ) X-BeenThere: linux-amlogic@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7723252019351356615==" Sender: "linux-amlogic" Errors-To: linux-amlogic-bounces+linux-amlogic=archiver.kernel.org@lists.infradead.org --===============7723252019351356615== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cbcddztjwsr2blmi" Content-Disposition: inline --cbcddztjwsr2blmi Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Fri, Mar 24, 2023 at 11:23:09PM +0100, Heiner Kallweit wrote: > This adds pwm support for (at least) the s4 chip family. The extension > is based on the vendor driver that can be found at [0]. There the > version with the new clock handling is called meson-v2-pwm. > Central change is that the clock is now fully provided by the SoC clock > core. The multiplexer isn't any longer part of the pwm block. >=20 > This was tested on a sc2-based system that uses the same pwm block. >=20 > [0] https://github.com/khadas/linux/blob/khadas-vims-5.4.y/drivers/pwm/pw= m-meson.c >=20 > Signed-off-by: Heiner Kallweit > --- > Adding the amlogic,meson-s4-pwm compatible to the documentation was part > of the yaml conversion already. This refers to https://lore.kernel.org/linux-pwm/3edc5ba6-bf3d-e45b-377a-9e7ece7642a7@gmai= l.com Does the external mux clk behave in the same way as the internal ones before? (I.e. it can select one of a few parents and has a single divider?) > --- > drivers/pwm/pwm-meson.c | 38 ++++++++++++++++++++++++++++++++++---- > 1 file changed, 34 insertions(+), 4 deletions(-) >=20 > diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c > index 16d79ca5d..7a93fdada 100644 > --- a/drivers/pwm/pwm-meson.c > +++ b/drivers/pwm/pwm-meson.c > @@ -98,6 +98,7 @@ struct meson_pwm_channel { > struct meson_pwm_data { > const char * const *parent_names; > unsigned int num_parents; > + unsigned int ext_clk:1; > }; > =20 > struct meson_pwm { > @@ -158,6 +159,7 @@ static int meson_pwm_calc(struct meson_pwm *meson, st= ruct pwm_device *pwm, > struct meson_pwm_channel *channel =3D &meson->channels[pwm->hwpwm]; > unsigned int duty, period, pre_div, cnt, duty_cnt; > unsigned long fin_freq; > + int err; > =20 > duty =3D state->duty_cycle; > period =3D state->period; > @@ -165,6 +167,14 @@ static int meson_pwm_calc(struct meson_pwm *meson, s= truct pwm_device *pwm, > if (state->polarity =3D=3D PWM_POLARITY_INVERSED) > duty =3D period - duty; > =20 > + if (meson->data->ext_clk) { err could be local to this block. > + err =3D clk_set_rate(channel->clk, 0xffffUL * NSEC_PER_SEC / period); > + if (err) { > + dev_err(meson->chip.dev, "failed to set pwm clock rate\n"); > + return err; > + } > + } > + > fin_freq =3D clk_get_rate(channel->clk); > if (fin_freq =3D=3D 0) { > dev_err(meson->chip.dev, "invalid source clock frequency\n"); > @@ -173,10 +183,14 @@ static int meson_pwm_calc(struct meson_pwm *meson, = struct pwm_device *pwm, > =20 > dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq); > =20 > - pre_div =3D div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL); > - if (pre_div > MISC_CLK_DIV_MASK) { > - dev_err(meson->chip.dev, "unable to get period pre_div\n"); > - return -EINVAL; > + if (meson->data->ext_clk) { > + pre_div =3D 0; > + } else { > + pre_div =3D div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL); > + if (pre_div > MISC_CLK_DIV_MASK) { > + dev_err(meson->chip.dev, "unable to get period pre_div\n"); > + return -EINVAL; > + } > } > =20 > cnt =3D div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * (pre_div + 1)); > @@ -445,6 +459,10 @@ static const struct meson_pwm_data pwm_g12a_ee_data = =3D { > .num_parents =3D ARRAY_SIZE(pwm_g12a_ee_parent_names), > }; > =20 > +static const struct meson_pwm_data pwm_s4_data =3D { > + .ext_clk =3D 1, > +}; > + > static const struct of_device_id meson_pwm_matches[] =3D { > { > .compatible =3D "amlogic,meson8b-pwm", > @@ -478,6 +496,10 @@ static const struct of_device_id meson_pwm_matches[]= =3D { > .compatible =3D "amlogic,meson-g12a-ao-pwm-cd", > .data =3D &pwm_g12a_ao_cd_data > }, > + { > + .compatible =3D "amlogic,meson-s4-pwm", > + .data =3D &pwm_s4_data > + }, > {}, > }; > MODULE_DEVICE_TABLE(of, meson_pwm_matches); > @@ -493,6 +515,14 @@ static int meson_pwm_init_channels(struct meson_pwm = *meson) > for (i =3D 0; i < meson->chip.npwm; i++) { > struct meson_pwm_channel *channel =3D &meson->channels[i]; > =20 > + if (meson->data->ext_clk) { > + snprintf(name, sizeof(name), "clkin%u", i); > + channel->clk =3D devm_clk_get(dev, name); > + if (IS_ERR(channel->clk)) > + return PTR_ERR(channel->clk); > + continue; > + } > + This requires a binding change, right? Would it make sense to drop the ext_clk flag and determine that by trying to get the clk and if it's there, assume ext_clk would have been set? Also I wonder if it would make sense to use the same name as used when the mux clk is internal, i.e. reuse name from the line below. > snprintf(name, sizeof(name), "%s#mux%u", dev_name(dev), i); Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | https://www.pengutronix.de/ | --cbcddztjwsr2blmi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmQerrQACgkQj4D7WH0S /k4vTwf/UkaodtBVn/0ZrwQmJxej9+0HFUE32MQH+p0jK3sidIhmwnLsvA7BHfnc nXL8sysq+nTYhOC9mvCLiaNwzI0Hmt84dal3bhxGvqRMq1MdbABsKzIfqWObSKXm UuBq2H7WLdBPWV99NzrLsDs3tOQkMPLZ3/ukYJHTne710GYhz4lVnRQrvArBUtUz JaKohK5e8x/cRHfTQ8R/Qb6V2P3fsXyXW2n5NY+Zt2tLbV2qTiStH5Jf6/JVlAi0 aX+5WkNcw9d7u9UdLjOBc1gbSQYKg6n/h2+vvw8KFmzk7ovWbHGCUGWWg8muDDya 0oLwU2aBT7GPaeEfcNPnKoNfQWJ6Bg== =YDLT -----END PGP SIGNATURE----- --cbcddztjwsr2blmi-- --===============7723252019351356615== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-amlogic mailing list linux-amlogic@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-amlogic --===============7723252019351356615==--