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=-5.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 170D4C433E0 for ; Fri, 15 Jan 2021 12:18:01 +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 BFFC420691 for ; Fri, 15 Jan 2021 12:18:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BFFC420691 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=denx.de 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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=M0wcsICll8YgZh6PXirRM733+QSdGvP1I1jCQBOaz2M=; b=WrfAH0vGlAj1qUVh0cmIvW2OQ +TnhbBgcWxfx+byIWhMEpyzqsuoKdGD70+EhqykhNoBRgTEGa+39lm4Ry6HB0XieXS040eRyn0SFe USrf1p3oPsyE+ACv7/tZ/2BGt/y6R/E3VzsdF4C1xmG8P9G0r2YxqFnctLCYamz8er792n+V+b+Q6 gQc35WQgNwJY0KECF8kmd0OAwuXojkMs1kS0R3N8wW970h2prnB0Juuk89jiXsxKCs/lt9W9+Gbzp aR1Vy4NMvSDsUAvA2Wr4XATHQb//5pOISLOhT5A3zacKQ6I/vfUdMwSMqXIpDEfhjD2Bv8ou/uivY YKkaNrfRQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0O1s-00089W-JC; Fri, 15 Jan 2021 12:16:36 +0000 Received: from mail-out.m-online.net ([212.18.0.10]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l0O17-0007mI-D9 for linux-arm-kernel@lists.infradead.org; Fri, 15 Jan 2021 12:15:51 +0000 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DHKrz2N3Pz1ryXJ; Fri, 15 Jan 2021 13:15:46 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DHKry3PQTz1tYVw; Fri, 15 Jan 2021 13:15:46 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id RIQA9dESM_Vn; Fri, 15 Jan 2021 13:15:44 +0100 (CET) X-Auth-Info: iJ3FXQe3H4c5EUgVL6k9wP0dmqj0Ijp5uE88204o3Yk= Received: from [IPv6:::1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 15 Jan 2021 13:15:44 +0100 (CET) Subject: Re: [PATCH 3/4] [RFC] ARM: dts: stm32: Add mux for ETHRX clock To: Alexandre TORGUE , linux-arm-kernel@lists.infradead.org References: <20210106204347.475920-1-marex@denx.de> <20210106204347.475920-3-marex@denx.de> From: Marek Vasut Message-ID: <73f6d2cc-8dd7-b005-7faa-db9956f46aa5@denx.de> Date: Fri, 15 Jan 2021 13:15:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210115_071550_216203_0C9A2EE1 X-CRM114-Status: GOOD ( 27.62 ) 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 Coquelin , linux-stm32@st-md-mailman.stormreply.com, Alexandre Torgue , Patrick Delaunay , Patrice Chotard Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 1/14/21 6:08 PM, Alexandre TORGUE wrote: > Hi Marek Hi, > On 1/6/21 9:43 PM, Marek Vasut wrote: >> The implementation of ETH_RX_CLK/ETH_REF_CLK handling currently does not >> permit selecting the clock input from SoC pad. To make things worse, the >> implementation of this is partly present and is split between the clock >> driver and dwmac4 driver. Moreover, the ETHRX clock parent is incorrect. > > Sorry but I don't understand which configuration is missing. I think we > can handle all possible cases for RMII. At the glue layer > (dwmac-stm32.c) clocks gates and syscfg are set regarding device tree > binding (see the tab in dwmac-stm32.c). You could have a look here for > more details: > https://wiki.st.com/stm32mpu/wiki/Ethernet_device_tree_configuration > > Regarding the clock parent, yes it is not at the well frequency if you > want to select this path. Our current "clock tree" is done to fit with > our ST reference boards (we have more peripherals than PLL outputs so we > have to make choices). So yes for customer/partners boards this clock > tree has to be modified to better fit with the need (either using > assigned-clock-parent or by modifying bootloader clock tree (tf-a or > u-boot)). I don't think you handle all the configuration options, but I might also be confused. See Figure 83. Peripheral clock distribution for Ethernet in the MP1 datasheet for the below. The current setup I have needs 50 MHz on SoC pad PA1 to drive the PHY clock, and uses eth_clk_fb to supply ETH_RX_CLK. However, the 50 MHz is sourced directly from PLL4P, which then has to run at 50 MHz and that in turn reduces clock frequency for other blocks connected to PLL4P (e.g. SDMMC, where the impact is noticable). So, what I want to model here is this: PLL4P = 100 MHz MCO2 is supplied by PLL4P and set to /2 , so MCO2 = 50 MHz SoC pad PG2 is set as MCO2 output, thus a source of 50 MHz signal SoC pad PA1 is set as ETH_RX_CLK and connected to PG2 This works fine in practice, except it cannot be modeled using current DT bindings, even though it should be possible to model it. >> First, the ETHRX clock in clk-stm32mp1.c only represents the ETHRXEN >> gate, >> however it should represent also ETH_REF_CLK_SEL mux. The problem is that >> the ETH_REF_CLK_SEL mux is currently configured in the DWMAC4 driver and >> the ETH_REF_CLK_SEL bit is part of SYSCFG block, not the DWMAC4 or the >> clock block. > > dwmac4-stm32 doesn't contain code for dwmac4 but it contains the glue > around the dwmac4: syscfg, clocks ... The problem is that dwmac4-stm32 isn't the right place to configure the ETHRX clock mux, that should be in the clock driver. So the stm32 clock driver should have SYSCFG handle and configure ETH_REF_CLK_SEL mux. The "st,eth-ref-clk-sel" DT prop would then not be needed at all, as the reference clock select would be configured using assigned-clocks in DT. The default assigned-clocks should be eth_clk_fb , but the user can override it in the DT and provide another clock source (e.g. in my case, that would be PLL4P->MCO2->ETHRX). >> Second, the ETHRX parent clock is either eth_clk_fb (ETHCK_K) or external >> ETH_RX_CLK/ETH_REF_CLK_SEL, it is never CK_AXI. > > Why CK_AXI ? See drivers/clk/clk-stm32mp1.c: 1895 PCLK(ETHRX, "ethrx", "ck_axi", 0, G_ETHRX), [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel