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 15E19C433E0 for ; Tue, 26 Jan 2021 19:13:33 +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 D0D52206A1 for ; Tue, 26 Jan 2021 19:13:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D0D52206A1 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=8urJizCfvR9gtMnM7ubivwpUP0wqivHBoizGdbezMtM=; b=vn0ucFA45HEr9LP9IkHbkjw/K JDxj5g+01s9asVq8wguzsvcTAvgt7JRlMbzBbmjDhfn8YejagIm8EmjjCl0CQ13jSklxAgiS1Ouj6 VGa+wYf5y4Scp2noIIu7HG2DFQYXRgWp/kJ/ZYXIA1RyJcwzDgB29ySFGYW0Bwceei/CjBWblZ2rC ZVpJuKclF1UkJC1tRQ0sACnqwRsx9VQ+fkEpb/VN4EnCYZ7yhzvrOEFRTA8dF6Jxa8mJPPDacnRQO ONQIZNm9L+QX5Qw7+COXZ9qFNuZx7P70I9hSHWUBreYlyfDwgEJ5r6ccXzkDGRxYR15F1LroDDJY3 /UbISeiJw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4TkF-0002PG-87; Tue, 26 Jan 2021 19:11:19 +0000 Received: from mail-out.m-online.net ([212.18.0.9]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4TkC-0002Od-CC for linux-arm-kernel@lists.infradead.org; Tue, 26 Jan 2021 19:11:17 +0000 Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4DQGYF6FhGz1qtdy; Tue, 26 Jan 2021 20:11:13 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4DQGYF4FS4z1sP6X; Tue, 26 Jan 2021 20:11:13 +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 OMhAGWVwO4_a; Tue, 26 Jan 2021 20:11:11 +0100 (CET) X-Auth-Info: JnPaiCUI0EhaLPPGr5oGnK/F64fp8jvk6cqfY1p+sfI= 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; Tue, 26 Jan 2021 20:11:11 +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> <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: Marek Vasut Message-ID: Date: Tue, 26 Jan 2021 20:11:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 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-20210126_141116_628981_7D51C9DA X-CRM114-Status: GOOD ( 21.49 ) 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 5:47 PM, Alexandre TORGUE wrote: > > > 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. Why? It can be safely turned off if it is only used to supply ETHRX. And if the clock tree is correctly modeled, that is what happens. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel