Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4572348ybe; Mon, 16 Sep 2019 14:42:13 -0700 (PDT) X-Google-Smtp-Source: APXvYqwRWlAcJd/qe9TU1kQuNmEhQWwy1ofL5vs+t2E4p7PfXNbEm0OZn2r3nbjalADVEpRQ6Ff8 X-Received: by 2002:a17:907:40bc:: with SMTP id nu20mr1928976ejb.309.1568670133493; Mon, 16 Sep 2019 14:42:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568670133; cv=none; d=google.com; s=arc-20160816; b=lY1qRsN9ur3bhrUuO/y0O3EzzUsWuVqD6ZRlGF9BIoJCc6E8d+CCKOoNCuHA4v9BBz i9+omC+jyj9teDqUsmcKoDO2iKaOHB3h5FFSqJ8EBrNQeWOzrkDrIuUGVbBZDgP0SYdY O/WEaGypaZ5E9+xZY7VOM+40ECPfjc1g06vYZDOB+V1aDdsIjMGKcYHlrRK7SM64H5Cl WOTss0pC2UvHmnNoauR91f4MhDhokcx63UN3wwxE8BrDGxC1a/x2ByTi6xi2cCOcSvYc iC9tXDeJG/UXiSou0rPigmcPQZUWraGy92tCE0ze80FLpweQVCWtQVLQ6zydxDOCfcqt bi2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:user-agent:subject:from :to:cc:references:in-reply-to:content-transfer-encoding:mime-version :dkim-signature; bh=eNwbU28xRRvzu4sknqcMF6+kBklCAiw6U+pfs/Q0+1Y=; b=IJylABC9iI4KCIV9LR3I2ooC1y98L6VSKFoXWzEoSSlW3A3ra8ehKRCk8FpJwkcYTR 30ab2KIl5gL+eFy6IFuwdkKkXatEbeG4gFOLlyB3NRwCJ5H+0VVF8fvwG91WnCAWucqb EHqGx2bvurAmkY5+Q6uwWzryhPbA2v+fASQXXrIzVEXBzix9YvWKP9LdeK8CVkVzAaD6 bjgzYmvT8q2r5slnZfMI255rLvfTLijqnjgZF7fQ415xdglOCBOtG3S8wujXl1u+DCiN kMlNoz1d2j4nqe9kuyf7nPYMg6VYtfFHYvzAB8XtTQkJrua4kn1KfKvFFw+knJnBSkb1 fxAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Evmir6os; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z3si92228ejx.33.2019.09.16.14.41.50; Mon, 16 Sep 2019 14:42:13 -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; dkim=pass header.i=@kernel.org header.s=default header.b=Evmir6os; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390473AbfIPScy (ORCPT + 99 others); Mon, 16 Sep 2019 14:32:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:45426 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728985AbfIPScx (ORCPT ); Mon, 16 Sep 2019 14:32:53 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E360720830; Mon, 16 Sep 2019 18:32:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568658773; bh=tGbgQXC0MLIMph9i8iPtfJHaRUqvcrZYiWDIfiq9yPg=; h=In-Reply-To:References:Cc:To:From:Subject:Date:From; b=Evmir6osXsKDL0nl+tpO2zp5kvCCW0B6ipAsu9ekOEBw1bL4nZHHVh2107KHj/IO+ N4dxjoCCW+6/sFLDp4Uk68KgYI5pLSnQcAkF6IUlAxT2bszMtvIwtHgFdUGdNOmTdk DN6En7/q67Kg+LQJFc4E4rDMkhZ2PhbGr/zk+kOQ= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20190815101613.22872-1-wen.he_1@nxp.com> <20190815101613.22872-2-wen.he_1@nxp.com> <20190816174624.115FC205F4@mail.kernel.org> <20190819182944.4AEAB22CF5@mail.kernel.org> Cc: Leo Li , "liviu.dudau@arm.com" To: "devicetree@vger.kernel.org" , "linux-clk@vger.kernel.org" , "linux-devel@linux.nxdi.nxp.com" , "linux-kernel@vger.kernel.org" , Mark Rutland , Michael Turquette , Rob Herring , Shawn Guo , Wen He From: Stephen Boyd Subject: RE: [EXT] Re: [v2 2/3] clk: ls1028a: Add clock driver for Display output interface User-Agent: alot/0.8.1 Date: Mon, 16 Sep 2019 11:32:52 -0700 Message-Id: <20190916183252.E360720830@mail.kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Wen He (2019-08-19 19:24:25) >=20 > >=20 > > > > > + > > > > > +static int plldig_clk_probe(struct platform_device *pdev) { > > > > > + struct clk_plldig *data; > > > > > + struct resource *mem; > > > > > + const char *parent_name; > > > > > + struct clk_init_data init =3D {}; > > > > > + struct device *dev =3D &pdev->dev; > > > > > + int ret; > > > > > + > > > > > + data =3D devm_kzalloc(dev, sizeof(*data), GFP_KERNEL); > > > > > + if (!data) > > > > > + return -ENOMEM; > > > > > + > > > > > + mem =3D platform_get_resource(pdev, IORESOURCE_MEM, 0); > > > > > + data->regs =3D devm_ioremap_resource(dev, mem); > > > > > + if (IS_ERR(data->regs)) > > > > > + return PTR_ERR(data->regs); > > > > > + > > > > > + init.name =3D dev->of_node->name; > > > > > + init.ops =3D &plldig_clk_ops; > > > > > + parent_name =3D of_clk_get_parent_name(dev->of_node, 0); > > > > > + init.parent_names =3D &parent_name; > > > > > > > > Can you use the new way of specifying clk parents with the > > > > parent_data member of clk_init? > > > > > > Of course, but I don't understand why need recommend to use this memb= er? > > > Is that the member parent_names will be discard in future? > > > > > > Here are definition of the clk-provider.h > > > /* Only one of the following three should be assigned */ > > > const char * const *parent_names; > > > const struct clk_parent_data *parent_data; > > > const struct clk_hw **parent_hws; > > > > > > For PLLDIG, it only has one parent. > >=20 > > Yes. Can you use clk_parent_data array and specify a DT index of 0 and = some > > name that would go into "clock-names" in the .fw_name member? >=20 > OK, but .fw_name used for to registering clk, current it registered with = fixed clk in dts . > I think should be specify a DT index of 0 and specify the unique name for= .name member. >=20 > I found have two ways to specify: > 1. declare clk_parent_data variable parent_data, and initialization with = clk_init_data, like this: > =20 > parent_data.name =3D of_clk_get_parent_name(dev->of_node, 0);=20 This isn't preferred because of_clk_get_parent_name() is DT specific and relies on the parent clk being registered before calling the function so that we can figure out the globally unique name. > parent_data.index =3D 0; >=20 > init.name =3D dev->of_node->name; > init.ops =3D &plldig_clk_ops; > init.parent_data =3D &parent_data; > init.num_parents =3D 1; >=20 > 2. Or use a static const array for here? And put the unique name and inde= x like this. > static const struct clk_parent_data parent_data[] =3D { > {.name =3D "phy_27m", .index =3D 0}, > }; >=20 > After then initialization with macro CLK_HW_INIT_PARENTS_DATA? Yes use option #2. But, don't even specify a .name if this is new code because .name is a fallback mechanism that is supposed to be used if you're migrating code from an older DT to a newer DT. I don't think that's happening here.