From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755197AbbESIaJ (ORCPT ); Tue, 19 May 2015 04:30:09 -0400 Received: from down.free-electrons.com ([37.187.137.238]:52228 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753896AbbESIaF (ORCPT ); Tue, 19 May 2015 04:30:05 -0400 Date: Tue, 19 May 2015 10:26:35 +0200 From: Maxime Ripard To: Jens Kuske Cc: Emilio =?iso-8859-1?Q?L=F3pez?= , Mike Turquette , Linus Walleij , Rob Herring , Chen-Yu Tsai , Vishnu Patekar , Hans de Goede , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [PATCH v2 03/10] clk: sunxi: Let divs clocks read the base factor clock name from devicetree Message-ID: <20150519082635.GW4004@lukather> References: <1431707940-19372-1-git-send-email-jenskuske@gmail.com> <1431707940-19372-4-git-send-email-jenskuske@gmail.com> <20150517130657.GD4004@lukather> <5559AF58.60508@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="64C3cv1XTIf1+2px" Content-Disposition: inline In-Reply-To: <5559AF58.60508@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --64C3cv1XTIf1+2px Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 18, 2015 at 11:22:32AM +0200, Jens Kuske wrote: > On 05/17/15 15:06, Maxime Ripard wrote: > > On Fri, May 15, 2015 at 06:38:53PM +0200, Jens Kuske wrote: > >> Currently, the sunxi clock driver gets the name for the base factor cl= ock > >> of divs clocks from the name field in factors_data. This prevents reus= ing > >> of the factor clock for clocks with same properties, but different nam= e. > >> > >> This commit makes the divs setup function try to get a name from > >> clock-output-names in the devicetree. It also removes the name field w= here > >> possible and merges the sun4i PLL5 and PLL6 clocks. > >> > >> The sun4i PLL5 clock doesn't have a output for the base factor clock, > >> so we still have to use the name field there. > >> > >> Signed-off-by: Jens Kuske > >> --- > >> drivers/clk/sunxi/clk-sunxi.c | 22 ++++++++++++---------- > >> 1 file changed, 12 insertions(+), 10 deletions(-) > >> > >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sun= xi.c > >> index 17cba4d..afe560c 100644 > >> --- a/drivers/clk/sunxi/clk-sunxi.c > >> +++ b/drivers/clk/sunxi/clk-sunxi.c > >> @@ -708,18 +708,10 @@ static const struct factors_data sun4i_pll5_data= __initconst =3D { > >> .name =3D "pll5", > >> }; > >> =20 > >> -static const struct factors_data sun4i_pll6_data __initconst =3D { > >> - .enable =3D 31, > >> - .table =3D &sun4i_pll5_config, > >> - .getter =3D sun4i_get_pll5_factors, > >> - .name =3D "pll6", > >> -}; > >> - > >> static const struct factors_data sun6i_a31_pll6_data __initconst =3D { > >> .enable =3D 31, > >> .table =3D &sun6i_a31_pll6_config, > >> .getter =3D sun6i_a31_get_pll6_factors, > >> - .name =3D "pll6x2", > >> }; > >> =20 > >> static const struct factors_data sun5i_a13_ahb_data __initconst =3D { > >> @@ -1099,7 +1091,7 @@ static const struct divs_data pll5_divs_data __i= nitconst =3D { > >> }; > >> =20 > >> static const struct divs_data pll6_divs_data __initconst =3D { > >> - .factors =3D &sun4i_pll6_data, > >> + .factors =3D &sun4i_pll5_data, > >> .ndivs =3D 4, > >> .div =3D { > >> { .shift =3D 0, .table =3D pll6_sata_tbl, .gate =3D 14 }, /* M, SAT= A */ > >> @@ -1141,6 +1133,7 @@ static void __init sunxi_divs_clk_setup(struct d= evice_node *node, > >> struct clk_gate *gate =3D NULL; > >> struct clk_fixed_factor *fix_factor; > >> struct clk_divider *divider; > >> + struct factors_data factors =3D *data->factors; > >> void __iomem *reg; > >> int ndivs =3D SUNXI_DIVS_MAX_QTY, i =3D 0; > >> int flags, clkflags; > >> @@ -1149,8 +1142,17 @@ static void __init sunxi_divs_clk_setup(struct = device_node *node, > >> if (data->ndivs) > >> ndivs =3D data->ndivs; > >> =20 > >> + /* Try to find a name for base factor clock */ > >> + for (i =3D 0; i < ndivs; i++) { > >> + if (data->div[i].self) { > >=20 > > I'm not sure we should expect the factor clock to have a self factor. >=20 > Maybe not, but in that case it would fall back to the name provided in > the factors_data struct, as it is the case for sun4i pll5. Which doesn't really solve the underlying issue, just make it work in your (pll6/pll8) case. =20 > > what about taking the first output and taking the substring up to the > > first "_" ? >=20 > That only works for the sun[457]i pll5 & pll6, for sun[68]i the base > clock name would have to be "pll6x2". Why? It's called pll6 in the datasheet, it should really be called pll6. The fact that there is some fixed factors or dividers on some children only impacts those children, and not the system as a whole. And the fact that the "base" clock is pll6x2 and not pll6 itself is very debatable. How do you know which clock is the base one? Most clocks are actually using pll6 as a reference. Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com --64C3cv1XTIf1+2px Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVWvO7AAoJEBx+YmzsjxAgkQsP/1Tj8BWDiT5h8jo5BbDYZo5l RA6qxzCOpz9ZVm/mqQDqRE5IaT0P1Kl6FjAVmfiVJinRjx0jJJMNF2MJIfDxuZho Bt18M4dG6akHHWFDgcAPlJO0XLyjmile8VCF6HleNbkGfa9Ym11zF5GT80DBK7Um 2GJBupzlKoErEqpqKwU3rzlSNaC66oM7WE/j9LDr+DIY9UgCX8g4a++sIGZ6TC6u vKHMjxiJ15htPjpU4HsI6CMd66X/G/5ROhOVPYTnef7zqBRIXKNiVu2cKXI8hwaZ gZ+gDhTRUeiko6yjP1VW+ivkejXIffnSAonZA0lhxow66ooQmwHWvH1ECnr/dJ5k MvJ+jbad+TvHPVllcMFElA0Q3nWQAvXGMXVDDsYgW/yXpyl51LHqppc7OtmrqYcV a3/h4aO36U6rHij6WhVJIJy3P6dOX/P4QYLFVcIEUQG3c+5CSSN+vLN5D3VtBQsu HLJnpbYIN04q84YTsH4dHPufHX4+YTV4tvT/a2QuolTGnVkYNHTFY5I54kI3LdoX /WvHqA7FPlc9UlGoGCg/kt0U4KmhXZchcbQ1dOc55nCONWY9S8Wjz4hb7gYbEExw ZKVp1buNHkkFLr6eWmJhM+uhJLDfs2lcOeSe/qmhpkU7VZPcwf19tKbD+078Xlmx y5FNnn41R2IlV2QdhrQY =L1Xk -----END PGP SIGNATURE----- --64C3cv1XTIf1+2px--