Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3218530ybc; Mon, 25 Nov 2019 10:50:15 -0800 (PST) X-Google-Smtp-Source: APXvYqxhexwUwjKFV6g0yBPB8bdjzA/Ty2X/Zx3PCa3cBuBWxaPfvKTnOxHsrPv+nIcwbxPqGz1r X-Received: by 2002:a17:906:6a43:: with SMTP id n3mr38507114ejs.31.1574707815118; Mon, 25 Nov 2019 10:50:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574707815; cv=none; d=google.com; s=arc-20160816; b=qLfbLyfGUa/BMZR2eJMzV1feChL6OZxOF4xcGJgBMlfDCcQiaALxjjf74AZH/pMtyi dEFQNA/KQxAlVgURGdDOt8oWpDw8d9O0vD2vEn/otVlSvkcs2SHpXowWe4wrOcyw1mQL X2iwAib6oEcgzxje+uBMnupb5ZWI2D1eEsBDuf2bQQnqjiYPveKgZbeVxKP4Cridd1oR vGRfTGz3tq8DKtGZu9d1Hee4zjtYjd00ToheqWa09zqsQwknKX1Fo1AQbMXSDXSU3Fla A2pXaEndDR43IY9hUZ7AMWOe8P9/MwtRU4Uc1uLCcthK2fXsejFjumuPQoznPi9euWIh tYGA== 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:to:cc:from :subject:references:in-reply-to:content-transfer-encoding :mime-version:dkim-signature; bh=djhyZJDtxB70JBGj3o4DS80jcr7ceSVnPnc8G1l/Mrk=; b=GhM0S2jWU21O7htMjZlv43MZE4kAEtI/pEqrtRXJWy72m4XntWJ4Z9EajOD4qk1A0H 3AycSRftZw+hh7qsh7iLqYduWt86zavakddRL84BTM/0oZjL1Omw5T+q98yORBA81QRJ 4wzJylHSxlGfFDj8ygUAd7aGzOt88tssO+eDgVkpj1N6XUV8RtQjFiAOGocycGJqZfi0 xDF6plzO0+gnxNNSfWGN0r/L9Xh5lgGIsmo8+fksyDA1SxtvUW4DdxU3llkzuzVIu1ir QNiiNmZnDLBeIecW3SENhblzpOORDl2dW0KH9T9D7uceDAKUchUpbQagzLYLJv0cK440 EVeA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=ApvQiZNe; 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 a61si6104443edf.157.2019.11.25.10.49.50; Mon, 25 Nov 2019 10:50:15 -0800 (PST) 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=ApvQiZNe; 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 S1728916AbfKYQfW (ORCPT + 99 others); Mon, 25 Nov 2019 11:35:22 -0500 Received: from mail.kernel.org ([198.145.29.99]:49546 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728683AbfKYQfW (ORCPT ); Mon, 25 Nov 2019 11:35:22 -0500 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 D9F1920740; Mon, 25 Nov 2019 16:35:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574699722; bh=djhyZJDtxB70JBGj3o4DS80jcr7ceSVnPnc8G1l/Mrk=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=ApvQiZNesjcWJJDV0zN9Wjny9kGpbkQVYxD5zT+gHd8VYKOON1UigLALXqh7WEqUi ZR55Mj03230H0OrhDIQu5Nl7JVn2aJABxrVv10sBQGLwqGbUGz9ZFaM+sFXpw/VLDX QZCBTuUlAwqTSmn0zzaNOIaPfM6eeULQuWqPO/qY= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <20191025111338.27324-1-chunyan.zhang@unisoc.com> <20191025111338.27324-6-chunyan.zhang@unisoc.com> <20191113221952.AD925206E3@mail.kernel.org> <20191125013312.ACC2E2071A@mail.kernel.org> Subject: Re: [PATCH 5/5] clk: sprd: add clocks support for SC9863A From: Stephen Boyd Cc: Chunyan Zhang , Mark Rutland , Michael Turquette , Rob Herring , linux-clk , DTML , Linux Kernel Mailing List , Orson Zhai , Baolin Wang To: Chunyan Zhang User-Agent: alot/0.8.1 Date: Mon, 25 Nov 2019 08:35:21 -0800 Message-Id: <20191125163521.D9F1920740@mail.kernel.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Chunyan Zhang (2019-11-24 18:10:58) > On Mon, 25 Nov 2019 at 09:33, Stephen Boyd wrote: > > > > Quoting Chunyan Zhang (2019-11-17 03:27:15) > > > > > > Not sure if I understand correctly - do you mean that switch to use a > > > reference to clk_parent_data.hw in the driver instead? > > > like: > > > https://elixir.bootlin.com/linux/v5.4-rc7/source/drivers/clk/qcom/gcc= -sm8150.c#L136 > > > > > > > Yes something like that. > > > > > Since if I have to define many clk_parent_data.fw_name strings > > > instead, it seems not able to reduce the code size, right? > > > > Ideally there are some internal only clks that can be linked to their >=20 > If the *internal* clks should be in the same base address, then we > have many external clks as parents, since most of our clks are not > located according to modules which clks serve, but according to clk > type. >=20 > > parent with a single clk_hw pointer. That will hopefully keep the size >=20 > Since all clks used for a chip are defined in the same driver file, I > actually can use clk_hw pointer directly, that will cut down the size > of this driver code, and also easier for users to look for parents for > one clk (only need to look at driver file). >=20 > But not sure if you aggree this way? If all clks are in the same file then it sounds fine to just use clk_hw pointers everywhere. >=20 > > down somewhat. And if there are any external clks, they can be described > > in DT and then only the .fw_name field can be used and the fallback > > field .name can be left assigned to NULL. >=20 > Yes, I noticed that. But I still need to add many .fw_name, that will > not be a small count. >=20 Sure. The plan is to get rid of the array of string names to specify parents. We can debate the size and cost associated with moving away from that, but it won't change the overall message here that I'd like to see new drivers use the new way of specifying parents instead of using strings for topology description.