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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 9BFF9C10F14 for ; Thu, 10 Oct 2019 04:15:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74657218AC for ; Thu, 10 Oct 2019 04:15:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570680952; bh=7PY8feDlXkVWW2KYFarN3ehYZj6sWp1UyoI9DgEgCys=; h=In-Reply-To:References:From:To:Cc:Subject:Date:List-ID:From; b=QNcRZsNqeyQsNqe67KtAL6Wt0+u67Fv4qaH/0yIvdgjduC0lqFU3Ug/iVqr871Vdy ycrBpFq95MX8ZY0TEWpyNEa2ogy6U/PzgGLk8sJhUxYyZ4yvYCZrIdkUTKiTbNQr8v WPQ2cONp6qP/sgmO/P6+hoItZHl0bpIZsZz8jp/U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728388AbfJJEPw (ORCPT ); Thu, 10 Oct 2019 00:15:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:48610 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725774AbfJJEPw (ORCPT ); Thu, 10 Oct 2019 00:15:52 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6D7E0208C3; Thu, 10 Oct 2019 04:15:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1570680951; bh=7PY8feDlXkVWW2KYFarN3ehYZj6sWp1UyoI9DgEgCys=; h=In-Reply-To:References:From:To:Cc:Subject:Date:From; b=xmVp7TcRnycdRPLvxC2NqH2qj2fFayaLt8zo2n+Ue4voXI+miBM/1/iRcw8zqOFqo DDkomvqz4wOxakoWArZIIpY4Wp/EVuY8sJ9zuKpUA2n1oMy5ZX6WN/j/V18ZWD6nqG RJiH4KaJYx42Ym80geAwBFPRNHbP9XJ0SLNpSQ+c= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: References: <155389876377.20095.15037552865160559827@swboyd.mtv.corp.google.com> From: Stephen Boyd To: Manu Gautam , Marc Gonzalez , Michael Turquette Cc: Jeffrey Hugo , Bjorn Andersson , linux-clk , MSM , Evan Green , Douglas Anderson , Vinod Koul , Amit Nischal Subject: Re: [PATCH v1] clk: qcom: Skip halt checks on gcc_pcie_0_pipe_clk for 8998 User-Agent: alot/0.8.1 Date: Wed, 09 Oct 2019 21:15:50 -0700 Message-Id: <20191010041551.6D7E0208C3@mail.kernel.org> Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org Quoting Manu Gautam (2019-10-09 01:31:09) > On 3/30/2019 4:02 AM, Stephen Boyd wrote: > > Quoting Marc Gonzalez (2019-03-28 09:26:59) > >> On 25/03/2019 14:49, Marc Gonzalez wrote: > >> > >>> .enable_mask =3D BIT(0), > >> Actually, 5f2420ed2189 is not the only similar instance. > >> > >> $ git log --oneline -G BRANCH_HALT_SKIP drivers/clk/qcom | grep -v con= troller > >> 924a86bf9793 clk: qcom: Skip halt checks on gcc_pcie_0_pipe_clk for 89= 98 > >> 5f2420ed2189 clk: qcom: Skip halt checks on gcc_usb3_phy_pipe_clk for = 8998 > >> 2abf856202fd clk: qcom: gcc-msm8998: Disable halt check of UFS clocks > >> 5f75b78d3d67 clk: qcom: gcc-msm8996: Disable halt check on UFS tx clock > >> 12d807cd34b8 clk: qcom: gcc-msm8996: Disable halt check on UFS clocks > >> 096abdc296f1 clk: msm8996-gcc: Mark halt check as no-op for USB/PCIE p= ipe_clk > >> 7d99ced8f4c6 clk: qcom: Add support for BRANCH_HALT_SKIP flag for bran= ch clocks > >> > > I keep asking Qualcomm engineers everytime this comes up why they can't > > fix their phy initialization sequence. > > > > Too bad they don't care anymore! >=20 >=20 > I have followed this up with QMP PHY hardware designers and they have > confirmed that QMP PHY must have pipe clock enabled at the beginning > of initialization sequence i.e. before bringing it out of reset and start= ing it. Awesome, thanks for following up. >=20 > Otherwise there is possibility of incorrect locking of pipe_interface/ > retime buffers in PHY. > Hence, for both USB and PCIe we have to continue to use HALT_SKIP flag. Does anything go wrong if we just leave these clks enabled forever out of boot? I'm inclined to rip the clks out and just slam the branch enable bit on all the time in gcc driver probe and return NULL to the callers of clk_get() for these clks. I don't see how this would be a problem because when the upstream phy is disabled this clk is disabled and so we aren't wasting power. It should also save us time and memory because now we don't have to call into the clk framework to turn it on and sequence that just right in the phy driver.