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 X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19D57C433FF for ; Mon, 12 Aug 2019 15:54:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id CCBCD20820 for ; Mon, 12 Aug 2019 15:54:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="I3Lx7rh1"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="FLw9OfRU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CCBCD20820 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=FyEPHXz2wIfcldLcMAlg2Y6yT++tNpwjEwpu57wVIQs=; b=I3Lx7rh1ssFYSF tHRHAZRc0mSgUUfRAOjEQeKw+a9Oevw2OjKApaeM2GcVJIqMVchxMS+zIHdxiK8hdofzn1ZcQj1k6 IZH3NidukGNVbbMTY4RVZrlcI0xPtfWPzgnS3biALXsnR0u7SYHPUa0ShD7B7DKZogTtQiKQHDIo2 av93U2qM0CZbeK4up0nkyboUVSHGkTznUUHtJN2OYpIMLnBv9EoUpZ2o8HlXRDpT8vWwrv3JZzMGr fIF7dWcxzOVl3IE4eI/Ljr+4OBCHAIRCbQp/60B7DUHUrrUjp6bKCZG508fpsnEHqoOLDA2M/fUfv Sz3D2TxD6zD0b7uXt2WA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hxCeu-0007ac-2y; Mon, 12 Aug 2019 15:54:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hxCer-0007aG-Oj for linux-arm-kernel@lists.infradead.org; Mon, 12 Aug 2019 15:54:55 +0000 Received: from X250 (37.80-203-192.nextgentel.com [80.203.192.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 02F5B20820; Mon, 12 Aug 2019 15:54:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1565625293; bh=GqbIVxc3IQ9SeU60mFNZIC6Nb287EK7LtdRjU/Ufx7U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FLw9OfRUlzvUhEmRtEKfgvMkxE0PeWjjuY+1TQMisiwwx+YRhJ5AiokPZ1ZnOmMVS /jV7XfO9GrRel6gy1O0jcCgWqAWnIAhhZaR6CsIoLY1b0vpErRfQ6NjeHDOMZrLiij 5HKbpaw3tryoGqsBC8WqkuO+z+XQEKAdz/gI+ELE= Date: Mon, 12 Aug 2019 17:54:42 +0200 From: Shawn Guo To: Aisheng Dong Subject: Re: [PATCH v3 02/11] dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree Message-ID: <20190812155440.GA12237@X250> References: <1563289265-10977-1-git-send-email-aisheng.dong@nxp.com> <1563289265-10977-3-git-send-email-aisheng.dong@nxp.com> <20190803135048.GL8870@X250.getinternet.no> <20190812130041.GD27041@X250> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190812_085453_847737_598D34DA X-CRM114-Status: GOOD ( 20.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree , Dong Aisheng , "sboyd@kernel.org" , Michael Turquette , Rob Herring , dl-linux-imx , Sascha Hauer , Fabio Estevam , linux-clk , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Aug 12, 2019 at 02:41:55PM +0000, Aisheng Dong wrote: > > From: Shawn Guo > > Sent: Monday, August 12, 2019 9:01 PM > > On Mon, Aug 05, 2019 at 11:27:20AM +0800, Dong Aisheng wrote: > > > > > +- compatible: Should be one of: > > > > > + "fsl,imx8qxp-lpcg" > > > > > + "fsl,imx8qm-lpcg" followed by > > "fsl,imx8qxp-lpcg". > > > > > +- reg: Address and length of the register set. > > > > > +- #clock-cells: Should be 1. One LPCG supports multiple > > clocks. > > > > > +- clocks: Input parent clocks phandle array for each clock. > > > > > +- bit-offset: An integer array indicating the bit offset > > for each clock. > > > > > > > > I guess that the driver should be able to figure bit offset from > > > > 'clock-indices' property. > > > > > > > > > > Yes, it can be done in theory. > > > Then the binding may look like: > > > sdhc0_lpcg: clock-controller@5b200000 { > > > ... > > > #clock-cells = <1>; > > > clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>, > > > <&conn_ipg_clk>, <&conn_axi_clk>; > > > clock-indices = <0>, <16>, <20>; > > > clock-output-names = "sdhc0_lpcg_per_clk", > > > "sdhc0_lpcg_ipg_clk", > > > "sdhc0_lpcg_ahb_clk"; > > > power-domains = <&pd IMX_SC_R_SDHC_0>; }; > > > > > > usdhc1: mmc@5b010000 { > > > ... > > > clocks = <&sdhc0_lpcg 16>, > > > <&sdhc0_lpcg 0>, > > > <&sdhc0_lpcg 20>; > > > clock-names = "ipg", "per", "ahb"; }; > > > > > > However, after trying, i found one limitation if using clock-indices > > > that users have to do a secondary search for the indices value from > > > clock names which is not very friendly. > > > > > > Formerly from the clock output names, user can easily get the clock > > > index as they're in fixed orders as output names, so very easily to > > > use. > > > e.g. > > > clocks = <&sdhc0_lpcg 1>, > > > <&sdhc0_lpcg 0>, > > > <&sdhc0_lpcg 2>; > > > > > > If using clock-indices, users have no way to know it's clock index > > > from clock output names order unless they do a secondary search from > > > the clock-indice array accordingly. > > > For example, for "sdhc0_lpcg_ahb_clk", user can easily know its > > > reference is <&sdhc0_lpcg 2>. > > > But if using clock-indice, we need search clock-indices array to find > > > its reference becomes <&sdhc0_lpcg 20>. So this seems like a drawback > > > if using clock-indices. > > > > Shouldn't we have constant macro defined for those numbers, so that both > > 'clock-indices' and 'clocks' of client device can use? > > > > I think we can do it. > Does below one look ok to you? > #define IMX_LPCG_ CLK_0 0 > #define IMX_LPCG_ CLK_1 4 > #define IMX_LPCG_ CLK_2 8 > #define IMX_LPCG_ CLK_3 12 > #define IMX_LPCG_ CLK_4 16 > #define IMX_LPCG_ CLK_5 20 > #define IMX_LPCG_ CLK_6 24 > #define IMX_LPCG_ CLK_7 28 Looks fine to me, except the space in the middle of macro name, which compiler will complain anyway :) Shawn > > The usage will look like: > <&sdhc0_lpcg IMX_LPCG_CLK_5> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel