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 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E7D49C433EF for ; Sat, 11 Jun 2022 15:43:55 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 844F084411; Sat, 11 Jun 2022 17:43:53 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="LNXjp9aX"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6ADF184413; Sat, 11 Jun 2022 17:43:52 +0200 (CEST) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id EEDC18440D for ; Sat, 11 Jun 2022 17:43:49 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=seanga2@gmail.com Received: by mail-qt1-x830.google.com with SMTP id j8so1276029qtn.13 for ; Sat, 11 Jun 2022 08:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8Hc3TbytFe0YE8khZz3Kra9OrC20fRyv5o2WyfTTbog=; b=LNXjp9aXcSFTn9m5EJpzrV889Nze+pAllMibWwnHXeadr/JgV6VbtD7NWxrW/WEYZj 9zvMMVMkQgMGtJWLDtGTzzWuiXM589CH0jYice/RyZcuPXGW1KnpzWzKFbd+Qhtz09Ed hzDusa6IES+2xS6VwEvU/qr6wmAvr5x9YWeiKvbcQSkV6juNtpiZo9naB+SC/enFI328 KD+1bCSJkiAo5TJjV9e4rdAzohEe4UgZf7MLJbeib8Q1o6PRx94Ts7ysWLhQG0fpJgKy 7k9uPH6exJDl+dwtgnXL/ouiipgfmL8Rl2NfDXYYsiaoEjQBTxFQxV46O3bPzoBvYxcj v4kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8Hc3TbytFe0YE8khZz3Kra9OrC20fRyv5o2WyfTTbog=; b=4yhC2ZQ8jWh2tqxPJurqkQd3SzBVt+ar5byx/++kptM/XzwkgOLRYc1mvgTU9Ff7la 5RqbIh7fdJ7fQlrpufo8tNfy1fmKaPDpuv5uScnbpL4QuM1qAtV1aem1cH5yP0WpeOhG dxtmCXOVe//LAmydxVXdv/F6t9+nYSCEJY9SlvNWGxujL+3gpbepxtQPOVuxHyeehTw5 TDsdEH8gENUVbjTHEyC3314pLZ4dsauCC8VmoCB0nBCX0A8oeBtY2k+gw/ccA2cJhlqG rOnrgE83l/Em5gCMLAvYzUFNx9vGIhJOa8xN6iJ4Ve8YnXOJE/+LEbftBA+rkZuvQjLk uWUw== X-Gm-Message-State: AOAM532owP9hTLTnVYIjQ7whh97yZOXdEBmNAt5ms9wdEvSVjuZOx+zL t/X9IJtygO3zeSmsPNXutuA= X-Google-Smtp-Source: ABdhPJwIKPzkyucLec3MX8ECWY/C81y7v6stjyAo4KcJNyLvacBjQJsYsF7yMdKRfgXEwX4rIuS4Zw== X-Received: by 2002:ac8:5ac5:0:b0:304:fa16:1227 with SMTP id d5-20020ac85ac5000000b00304fa161227mr19643574qtd.37.1654962228666; Sat, 11 Jun 2022 08:43:48 -0700 (PDT) Received: from [192.168.1.201] (pool-173-73-95-180.washdc.fios.verizon.net. [173.73.95.180]) by smtp.gmail.com with ESMTPSA id j9-20020a05620a288900b006a67d257499sm2032522qkp.56.2022.06.11.08.43.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jun 2022 08:43:48 -0700 (PDT) Subject: Re: [PATCH 1/3] phy: stm32-usbphyc: add counter of PLL consumer To: Patrick DELAUNAY , Amelie Delaunay , u-boot@lists.denx.de Cc: Joe Hershberger , Patrice Chotard , uboot-stm32@st-md-mailman.stormreply.com References: <20220426123750.579726-1-patrick.delaunay@foss.st.com> <20220426143736.1.I15bd7c3c8c983d6a6cec3d2ee371d75fe72fcd41@changeid> <27373592-d6c9-ff00-799b-a2f04f4500b1@gmail.com> <0aeffe8a-b73a-5e3d-de89-9938d8d53150@foss.st.com> <8776d357-028b-0d21-cb90-4cbdd73f4ffb@foss.st.com> <78061a89-ab5e-af21-d02a-9deeece3e454@gmail.com> <4a7519b0-9bb7-f92e-3e73-7be0ba9959d7@foss.st.com> From: Sean Anderson Message-ID: <217c9525-9d3c-a6ed-0d3f-0830a534ae84@gmail.com> Date: Sat, 11 Jun 2022 11:43:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <4a7519b0-9bb7-f92e-3e73-7be0ba9959d7@foss.st.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean On 5/17/22 3:42 AM, Patrick DELAUNAY wrote: > Hi Sean, >=20 > On 5/11/22 18:48, Sean Anderson wrote: >> On 5/10/22 5:51 AM, Amelie Delaunay wrote: >>> Hi Patrick, >>> Hi Sean, >>> >>> On 5/9/22 16:37, Patrick DELAUNAY wrote: >>>> Hi Sean, >>>> >>>> On 5/8/22 20:21, Sean Anderson wrote: >>>>> On 4/26/22 8:37 AM, Patrick Delaunay wrote: >>>>>> Add the counter of the PLL user n_pll_cons managed by the 2 functi= ons >>>>>> stm32_usbphyc_pll_enable / stm32_usbphyc_pll_disable. >>>>>> >>>>>> This counter allow to remove the function stm32_usbphyc_is_init >>>>>> and it is a preliminary step for ck_usbo_48m introduction. >>>>> >>>>> Is it necessary to disable this clock before booting to Linux? If i= t isn't, >>>>> then perhaps it is simpler to just not disable the clock. >>>>> >>>>> --Sean >>>> >>>> >>>> No, it is not necessary, we only need to enable the clock for the fi= rst user. >>>> >>>> I copy the clock behavior from kernel, >>>> >>>> but I agree that can be simpler. >>>> >>>> >>>> Amelie any notice about this point ? >>>> >>>> Do you prefer that I kept the behavior - same as kernel driver - or = I simplify the U-Boot driver ? >>> >>> In case the PLL has not been disabled before Kernel boot, usbphyc Ker= nel driver will wait for the PLL pwerdown. >>> USB could also not being used in Kernel, so PLL would remain enabled,= and would waste power. >>> I am rather in favor of disabling the PLL. >> >> It should be disabled if clk_ignore_unused is not in the kernel parame= ters, >> as long as Linux is also aware of the clock. >> >> Generally, I would like to avoid refcounting if possible. Many U-Boot >> drivers do not disable their clocks (because they don't do any cleanup= ), >> so you can end up with the clock staying on anyway. >> >> --Sean >> >>> Regards, >>> Amelie >>> >>>> >>>> >>>> Patrick >>>> >>>> >>>>> >=20 > In general, I'm also in favor of not disabling the clock in U-Boot. >=20 > But this PLL with vdda1v1 and vdda1v8 dependency is requested for >=20 > - USBPHYC himself or >=20 > - source clock of RCC, >=20 >=20 > And we have have see many issue for this PLL initialization sequence / = dependencies. >=20 >=20 > So for clock support, I only reused the existing/working function calle= d by the PHY ops init & exit =3D >=20 > stm32_usbphyc_phy_init & stm32_usbphyc_phy_exit >=20 > =3D> the PLL and the associated VDD=C2=A0 are already deactivated on US= BPHYC exit. >=20 >=20 > And to be coherent I for the same for the clock to avoid conflict betwe= en these 2 users >=20 > (USBPHYC or RCC) as it is done also in Linux kernel. >=20 >=20 > Avoid to deactivate PLL on clock disable is a major objection or just a= advice? Just advice. If all of the clock's users call disable, then it is fine. --Sean