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 D56DFC433E0 for ; Tue, 26 Jan 2021 15:42:50 +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 86D35206A5 for ; Tue, 26 Jan 2021 15:42:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 86D35206A5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=foss.st.com 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=IeBtw+FYHG185G30RKlmXxn8N4bXpNnNf7d9EpFGgPo=; b=NorlabLV4CwqWCATtw0BN96Bm mV/fOAbD14Rusfr+alG5pphgGnglrJsM4RD1j8CZ/cHqyIbtltAuiA4l0wVHfvMeQG5/mURapBG+w 5flaJpli5yVCe59KA9wvTdSpexvkjj032k3WKK+QXNIGGouc2ky0wZi99dRo052ea95ZssSfMepUS K5NMIZRIzaXOw6I/3yqW4JO80FwzlQpZS5PH/7Pu+orxpChHBfS1NsJ683lu9Z8qeIF8slqTRo7vs MXBEW8Am1h51PUIVNhjG+zQTB2AE8bGD6gUW9PZ3f6hNXFDx/uLwWSAhKi+386qGhOYNx6YUr1Zr+ U8gEAHKow==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4QSW-0004Yh-2Y; Tue, 26 Jan 2021 15:40:48 +0000 Received: from mx08-00178001.pphosted.com ([91.207.212.93] helo=mx07-00178001.pphosted.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4QSS-0004XM-M7 for linux-arm-kernel@lists.infradead.org; Tue, 26 Jan 2021 15:40:46 +0000 Received: from pps.filterd (m0046661.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10QFC2f1020456; Tue, 26 Jan 2021 16:40:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=wXgynC/79CtvCwkExgL8YUI/Jvq124FdErwt4xPizxA=; b=0qw0BKewbpc+n23eC6FuYNgrEM47e/MiSWzHm5qfBllUkpZ77cgK24GKhIjNvuSIN/S3 CoHFOhPJwuSAnPoSfXbFcuPTpXutr5LZKjhUllPwW0yAma5TF0c6KrS81Z3ccP39foIv jPu7kK+MJde+utCqTupTGzzC5tFfgZbDsjkF/twhhjkzJYHmGjtTjIw4rEKryuM/EAq5 mH61Hid1gM2csFuWMoYkDcjTae9YSlNdy4Gcy4KQxabjpzZzuScseRskblakGEsaupzk AKowpJ4MoNw8brIN/PoYHCWptsi+2VXYUcnQSuUGnUrgqgc0HhnVuyFrwJEtZk2Nm3oY Sw== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 368bjn9wp7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jan 2021 16:40:38 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 150E710002A; Tue, 26 Jan 2021 16:40:38 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag2node3.st.com [10.75.127.6]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id F22D323BD42; Tue, 26 Jan 2021 16:40:37 +0100 (CET) Received: from lmecxl0912.lme.st.com (10.75.127.44) by SFHDAG2NODE3.st.com (10.75.127.6) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Jan 2021 16:40:37 +0100 Subject: Re: [PATCH 3/4] [RFC] ARM: dts: stm32: Add mux for ETHRX clock To: Marek Vasut , References: <20210106204347.475920-1-marex@denx.de> <20210106204347.475920-3-marex@denx.de> <73f6d2cc-8dd7-b005-7faa-db9956f46aa5@denx.de> <332e7c43-8489-d8b2-e8e1-1fb0d6fde1ee@foss.st.com> <3c5a4ac9-7874-2d4e-f353-5cf3ad79cfe1@foss.st.com> <9c41ae2b-06f2-b09f-d708-0f4ec96e67b6@denx.de> <57ff08b6-36c1-9e00-a55f-54bf8ade2b69@denx.de> From: Alexandre TORGUE Message-ID: <45443b53-3b48-afb6-b7d2-f84e0c33e85b@foss.st.com> Date: Tue, 26 Jan 2021 16:40:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <57ff08b6-36c1-9e00-a55f-54bf8ade2b69@denx.de> Content-Language: en-US X-Originating-IP: [10.75.127.44] X-ClientProxiedBy: SFHDAG3NODE1.st.com (10.75.127.7) To SFHDAG2NODE3.st.com (10.75.127.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-26_08:2021-01-26, 2021-01-26 signatures=0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210126_104045_053701_22871507 X-CRM114-Status: GOOD ( 21.78 ) 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/26/21 1:59 PM, Marek Vasut wrote: > On 1/26/21 11:54 AM, Alexandre TORGUE 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). >>>>>> >>>>>> Ok that's the common path to clock a PHY a 50MHz without using the >>>>>> ref_clk coming from the PHY. And yes I can understand that the >>>>>> drawback is huge). >>>>> >>>>> So lets fix it. >>>> >>>> There is no issue in code. It is just clock tree configuration >>>> issue. Either you don't use PLL4P for Ethernet (what you're doing) >>>> or you don't use PLL4P for SDMMC. But yes, there are not a lot of >>>> possibilities. >>> >>> I am supplying MCO2 with PLL4P, that is PLL4P->MCO2->ETHRX . To >>> enable this entire chain of clock, I need the correct clock tree. >>> Currently that cannot be modeled, can it? >>> >> >> Maybe I miss something, I thought your setup was like that: >> >> First clock path to your PHY: >> -------------------- >> >> PLL4P ---> MCO2 ---> X1 (PHY input clock which replaces crystal) >> It is not directly linked to the dwmac-stm32. You "just" provide a >> clock to MCO2. After that you can use MCO2 pins for any usages. >> >> Second clock patch: >> -------------------- >> >> 50MHz (refclk coming from phy) --> ETH_REF_CLK pad >> This one is already covered in dwmac-stm32. >> >> Why do you want to link the both clock paths ? > > Because the X1 (MCO2 output) is the same net as 50 MHz ETH_REF_CLK > input. MCO2 output is routed on a SoC pin and that is connected with a > wire to ETH_REF_CLK SoC pin (input). Ok I see, but I don't think you have to link both clocks. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel