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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 3299BC4361B for ; Tue, 15 Dec 2020 17:31:57 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 E2EB622ADC for ; Tue, 15 Dec 2020 17:31:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E2EB622ADC 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+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=merlin.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=yYRsBHRH+THCOB/ed7zASQt9riM6PpwH2q7AEQQU7eg=; b=oz9shAbqmAhe5E4a0u1mXVLLt 8hmQ/HnLXqWL5dInjy4RiNsSUuMW5CnDBeBq1SlzWP/7Xm35n6kjpxPFwklL3rlhtzoGjMEdHaGSt rfNzPcW1rktszOF9v+P4lGya63wQVEX+Cc6FOxhwH/0JEDSb7wcayztlDVNQFmXdcAXUB2tOV0+Zt qzJFGvnl93gWPqfyAq/wAGm/2aeLPECUo+RXZP8oj8x64KoYl1sgAIc+aEsPiCuuzU9LndoOm09QO BcvzuR2wSsZHRMkd10ERXdpGIyOeLSpuXm6UoYOrDjKfF2gZ0k/u21VmLvZl65ezbjE3VjTt+Y6CP 2rIU4xIYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpE9v-0006bY-R8; Tue, 15 Dec 2020 17:30:47 +0000 Received: from mail-oi1-f193.google.com ([209.85.167.193]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kpE9q-0006aA-Jo for linux-arm-kernel@lists.infradead.org; Tue, 15 Dec 2020 17:30:43 +0000 Received: by mail-oi1-f193.google.com with SMTP id d203so3011072oia.0 for ; Tue, 15 Dec 2020 09:30:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=f37RWrXwsiv+0EoW1Yj6ZpyoDuIYg2z238UxVLI0rTM=; b=jHMnX9B76ejr/ZSSlK6dB0BuY57Bpq41Sca2cyRTQGB952ZdwPzPno3itgbw0AKEWT OszKBb7q9ZQkfv1VqhZp2F8fj4IwBjh0/0MoqDN/i7dkeQdhuOFiOqHdJB0hEx9xQixH +QN+SEjUY61DkE5r/HSWvQiPhL0GIWxXrwr6qTnTzqPM4SWv0mEHhWSC8IhgMGZPRNIz uCE6Ug/ySbeUGx0yqNRa/MN7+AtPYV9KFi3SW40EJwi0SEqlmNdKKM6eYYkxweUnLKrX sk0h6NE6ldbLVYlOLXO27SlpokJJd4Uds7DE4EObPRVY/vi4K3zCha1hzxjjy+ifaI+p /joQ== X-Gm-Message-State: AOAM533JXUldX6LFGW9AQj5DrLbUCWDUd5AEbUrnxjWT/YFizC8aT+HS XV3giy1Pp2nI4+Xnt5jctWNeeVlsrw== X-Google-Smtp-Source: ABdhPJy+h89dvJUr6gfADjtGId8WiKWymjBfz57RzC+lV7rbruhDVmEpT328hNNnZ8Hu5ffbr8zbtA== X-Received: by 2002:aca:cd85:: with SMTP id d127mr21918090oig.59.1608053441932; Tue, 15 Dec 2020 09:30:41 -0800 (PST) Received: from xps15 (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id v17sm1517451oou.41.2020.12.15.09.30.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Dec 2020 09:30:41 -0800 (PST) Received: (nullmailer pid 4072081 invoked by uid 1000); Tue, 15 Dec 2020 17:30:39 -0000 Date: Tue, 15 Dec 2020 11:30:39 -0600 From: Rob Herring To: Serge Semin Subject: Re: [PATCH 05/25] dt-bindings: net: dwmac: Elaborate stmmaceth/pclk description Message-ID: <20201215173039.GA4072051@robh.at.kernel.org> References: <20201214091616.13545-1-Sergey.Semin@baikalelectronics.ru> <20201214091616.13545-6-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20201214091616.13545-6-Sergey.Semin@baikalelectronics.ru> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201215_123042_735834_E95690DB X-CRM114-Status: GOOD ( 25.44 ) 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: Maxime Ripard , devicetree@vger.kernel.org, Alexandre Torgue , Joao Pinto , netdev@vger.kernel.org, Giuseppe Cavallaro , linux-stm32@st-md-mailman.stormreply.com, linux-kernel@vger.kernel.org, Serge Semin , Alexey Malahov , Rob Herring , Jose Abreu , Pavel Parkhomenko , Maxime Coquelin , Lars Persson , Jakub Kicinski , Johan Hovold , Vyacheslav Mitrofanov , "David S. Miller" , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 14 Dec 2020 12:15:55 +0300, Serge Semin wrote: > 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 > --- > .../devicetree/bindings/net/snps,dwmac.yaml | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel