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 5DEE5C433DB for ; Tue, 26 Jan 2021 16:49:35 +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 1894622B3B for ; Tue, 26 Jan 2021 16:49:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1894622B3B 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=f7pfLL1bM4xG9lPok13VqR5KkCHbAePFaPoXcNTq/y0=; b=LPKJExTpduQRfPf1R6zQGKjUg kx8uZ+tKVxrpilbmAjHz5OvmlDHHrZScic2zHznzf1q2oD1UL0+SoY0PGHBHVz0R7vod5hQfKQiEL h3YO/HthsmxHZGjs7iaQfCQoCqlU+eeXSLyt8PcICT66wL5cxQ9PMhuqjrpmvpgcHCMAHSoHrh62z YkqqQCtmUSpwequ4gMlgaM3ymwzf8/77PlTg7XzrY/q0+jzfeQcClFfnz3vhdn/lez3/EhZD/H4Vv 417v0QR8FsFqnG8xvpf7DbBiKDX4hNTOiJ9vqlVMBPr9gapc+N4/8aHIMP444O77YYgPJMuFee2AE JSLzRXScQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4RVT-0003nv-Ut; Tue, 26 Jan 2021 16:47:55 +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 1l4RVR-0003mu-85 for linux-arm-kernel@lists.infradead.org; Tue, 26 Jan 2021 16:47:54 +0000 Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10QGhFaf013001; Tue, 26 Jan 2021 17:47:48 +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=vlLeGXsHsMnjnV3FmScq6oQRQ7q52q4oUzJsAS0IeXs=; b=cTkWNGF9LNMZasacEvdp8O29sCKZBqRCqRWgBcmgbXYtHYSvElL0pDXNb4GOVC4LZGT5 OjzjXbH/jX1RSxEscpgfRZhYpjtHrTZ7S8KZm2F2bZMdsdZ7u9MHIeBozhnrkbwiKunW ZuxcfK60DdieKnrk/8lmrRmyYyolf9TBk5s9OTSpN++kwo23zv4DiK5d1Th+AZJQ6dEF mKNbF6ZvNCH90swuY97WrECz6lewcCNiYBiP12QBRcSACJGNj8ziTjiyuW1csykV9dsV oqusg0HioF5e0KPZE/PQ8sRtSpOjocEI1OrFip+vGW2WK9BeEjeOlsY1zwR9PFfm84iy Dg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 3689tdtje8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jan 2021 17:47:48 +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 EFB7310002A; Tue, 26 Jan 2021 17:47:46 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag2node3.st.com [10.75.127.6]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id E15C02AD2C3; Tue, 26 Jan 2021 17:47:46 +0100 (CET) Received: from lmecxl0912.lme.st.com (10.75.127.47) by SFHDAG2NODE3.st.com (10.75.127.6) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Jan 2021 17:47:46 +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> <45443b53-3b48-afb6-b7d2-f84e0c33e85b@foss.st.com> <538d5520-7491-9cfe-7449-766d836784da@denx.de> From: Alexandre TORGUE Message-ID: Date: Tue, 26 Jan 2021 17:47:45 +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: <538d5520-7491-9cfe-7449-766d836784da@denx.de> Content-Language: en-US X-Originating-IP: [10.75.127.47] X-ClientProxiedBy: SFHDAG1NODE1.st.com (10.75.127.1) 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_09: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_114753_697058_D5A64868 X-CRM114-Status: GOOD ( 21.65 ) 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 4:42 PM, Marek Vasut wrote: > On 1/26/21 4:40 PM, Alexandre TORGUE wrote: >> >> >> 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. > > If I don't, then MCO2 will not have any consumer and would be turned off > by the kernel. I agree, but IMO the MCO clock should be declared with CLK_IGNORE_UNUSED flag in stm32mp1 clock driver. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel