Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4015594pxb; Mon, 8 Feb 2021 06:06:21 -0800 (PST) X-Google-Smtp-Source: ABdhPJzrrvUvXgQfesv1+nJqduz8OC7r1pO+455+agGojCvOuTM6BXAUGwp0mdlkKeurKwlfPzk+ X-Received: by 2002:a17:906:29d6:: with SMTP id y22mr6973431eje.306.1612793180653; Mon, 08 Feb 2021 06:06:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612793180; cv=none; d=google.com; s=arc-20160816; b=mLcCHZcSd++FdtLpQ6AKNg7L55kzIDV4MD6k5Cu7Md2O9WMUW1vku63u1uBB05tlVB vA6P25p3qcqGX0QZgns2v94Ais9feWV3J81nVLHTZ60GcB6nfOsiGIJMTsooBz+6TINJ 5Kmr3j9Eg0PaRo3qVOtX7umXHkjsMPvG5LyP/jzLopZekkWHBMmwUEZ0yq/4rBa81T0J y3/DR5yGY0vLbBNBfSM1a1eBGd0QLHt0pH1Y6CIFCn59jAsv55lbEM15ZBQgrQUKBs6B 8bBuWPS6dPHmfVrPLCwzUr52Ev39InKuknCgglR6M0doYTc1bFSHz/rPoZN3HAdYaJ3w SCfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=si+illOv5QofALAbmx6fGexjm7p2p4usb+svCBT2yao=; b=ktakTOdC9ILjdkeDEIIjYPCIyiohPWibO/EWPW1FyiK54AXk/uQhqhNtCMqGqllbb+ KIY4jkl9pkncvn6q8WkmHliQDkEYzGi4s9VcAK/fpZyZb1DbZNZQWt00v0IUt41k7ajE IVlgf02rNiHgofZNj4v/kRrtmHtwmWmYnS3UOyjRHkVARxijkX2o1/yOcZ+dQIrNKq3w tRU2UqnxZ9KAYRIhcm5WdB1Xi6n0ntzWqBO93Wzib205k4WFlAawqbTVq2lvkG01tx2W NYaYc3hDpP1dlVaCd/uRhuc8FrKHocaqJcPt+ZvqDr0wXoEPArKFDAwDNYFLnWq12GcQ hEWA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si11188754ejp.327.2021.02.08.06.05.44; Mon, 08 Feb 2021 06:06:20 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232415AbhBHOEV (ORCPT + 99 others); Mon, 8 Feb 2021 09:04:21 -0500 Received: from mail.baikalelectronics.com ([87.245.175.226]:57062 "EHLO mail.baikalelectronics.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230526AbhBHN5p (ORCPT ); Mon, 8 Feb 2021 08:57:45 -0500 From: Serge Semin To: Rob Herring , Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Jakub Kicinski , Johan Hovold , Maxime Ripard , Joao Pinto , Lars Persson CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Vyacheslav Mitrofanov , Maxime Coquelin , , , , , , Rob Herring Subject: [PATCH v2 05/24] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description Date: Mon, 8 Feb 2021 16:55:49 +0300 Message-ID: <20210208135609.7685-6-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20210208135609.7685-1-Sergey.Semin@baikalelectronics.ru> References: <20210208135609.7685-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Current clocks description doesn't provide a comprehensive notion about what "stmmaceth" and "pclk" actually represent from the IP-core manual point of view. The bindings file states: stmmaceth - "GMAC main clock", apb - "Peripheral registers interface clock". It isn't that easy to understand what they actually mean especially seeing the DW *MAC manual operates with clock definitions like Application, System, Host, CSR, Transmit, Receive, etc clocks. Moreover the clocks usage in the driver doesn't shade a full light on their essence. What inferred from there is that the "stmmaceth" name has been assigned to the common clock, which feeds both system and CSR interfaces. But what about "apb"? The bindings defines it as the clock for "peripheral registers interface". So it's close to the CSR clock in the IP-core manual notation. If so then when "apb" clock is specified aside with the "stmmaceth", it represents a case when the DW *MAC is synthesized with CSR_SLV_CLK=y (separate system and CSR clocks). But even though the "apb" clock is requested in the MAC driver, the driver doesn't actually use it as a separate CSR clock where the IP-core manual requires. All of that makes me thinking that the case of separate system and CSR clocks isn't correctly implemented in the driver. Let's start with elaborating the clocks description so anyone reading the DW *MAC bindings file would understand that "stmmaceth" is the system clock and "pclk" is actually the CSR clock. Indeed in accordance with sheets depicted in [1]: system/application clock can be either of: hclk_i, aclk_i, clk_app_i; CSR clock can be either of: hclk_i, aclk_i, clk_app_i, clk_csr_i. (Most likely the similar definitions present in the others IP-core manuals.) So the CSR clock can be tied to the application clock considering the later as the main clock, but not the other way around. In case if there is only "stmmaceth" clock specified in a DT node, then it will be considered as a source of clocks for both application and CSR. But if "pclk" is also specified in the list of the device clocks, then it will be perceived as the separate CSR clock. [1] DesignWare Cores Ethernet MAC Universal Databook, Revision 3.73a, October 2013, p. 564. Signed-off-by: Serge Semin Reviewed-by: Rob Herring --- .../devicetree/bindings/net/snps,dwmac.yaml | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 4dda9ffa822c..21e53427551c 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -116,8 +116,16 @@ properties: maxItems: 5 additionalItems: true items: - - description: GMAC main clock - - description: Peripheral registers interface clock + - description: + GMAC main clock, also called as system/application clock. + This clock is used to provide a periodic signal for the DMA/MTL + interface and optionally for CSR, if the later isn't separately + clocked. + - description: + Peripheral registers interface clock, also called as CSR clock. + MCI, CSR and SMA interfaces run on this clock. If it's omitted, + the CSR interfaces are considered as synchronous to the system + clock domain. - description: PTP reference clock. This clock is used for programming the Timestamp Addend Register. If not passed then the system -- 2.29.2