From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeffrey Hugo Subject: Re: [PATCH v2 1/3] arm64: dts: qcom: msm8998: correct xo clock name Date: Fri, 7 Dec 2018 07:58:52 -0700 Message-ID: <8a1ec3da-0c07-7c05-cf5b-f1fef001c972@codeaurora.org> References: <1542314695-24071-1-git-send-email-jhugo@codeaurora.org> <1542314695-24071-2-git-send-email-jhugo@codeaurora.org> <0ba54ffd-1d47-5ae9-ae9c-4a03d57e6ff3@codeaurora.org> <20181205164843.GB1492@tuxbook-pro> <05b9ee40-d51e-3f80-8ca4-217fa6fbd51c@codeaurora.org> <154404384283.88331.2522037578224950651@swboyd.mtv.corp.google.com> <14cad8f0-7388-16a0-b1ba-4cd5a469a17e@codeaurora.org> <154404615332.88331.10043835293734703587@swboyd.mtv.corp.google.com> <154412124335.88331.16092762627424651997@swboyd.mtv.corp.google.com> <00756abc-6e60-41cb-66bf-a7c9770dc2c9@free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <00756abc-6e60-41cb-66bf-a7c9770dc2c9@free.fr> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Marc Gonzalez , Stephen Boyd , Andy Gross Cc: MSM , Georgi Djakov , Linux ARM , Bjorn Andersson List-Id: linux-arm-msm@vger.kernel.org On 12/7/2018 2:03 AM, Marc Gonzalez wrote: > On 06/12/2018 19:34, Stephen Boyd wrote: >> Quoting Jeffrey Hugo (2018-12-05 15:04:01) >>> On 12/5/2018 2:42 PM, Stephen Boyd wrote: >>>> Quoting Jeffrey Hugo (2018-12-05 13:20:07) >>>>> On 12/5/2018 2:04 PM, Stephen Boyd wrote: >>>>>> Quoting Jeffrey Hugo (2018-12-05 09:03:54) >>>>>> >>>>>> I don't quite understand the patch in general. The xo_board clk should >>>>>> always exist in DT and the fixed factor clk in GCC is there until the >>>>>> rpm clk driver can control the XO clk state vote for the kernel. >>>>> >>>>> Sorry, this wasn't apparent. It doesn't seem like this "requirement" is >>>>> captured anywhere. >>>> >>>> Agreed! >>>> >>>>> >>>>> As far as the SD clocks are concerned, they are defined in GCC, and >>>>> eventually have a root parent called "xo". "xo" isn't defined anywhere, >>>>> so the SD clocks can't really be used, and the hardware doesn't come up. >>>>> This patch "fixed" that, but I missed the link to the rpm driver that >>>>> Marc pointed out. >>>> >>>> Hmm ok. The SD DT node should just point to the xo_board clk for now and >>>> later on it can be changed to use the rpm clk when the rpm node is >>>> created. >>>> >>>>> >>>>> >>>>>> >>>>>> If anything, change the DT node to be named xo-board instead of xo_board >>>>>> because that matches DT naming schemes and then add a clock-output-names >>>>>> = "xo_board" property to it so that we keep the underscore. >>>>> >>>>> I see this now, and I agree with it, but then SD goes back to a broken >>>>> state because there is "xo" clock for GCC. Its not quite clear to me >>>>> how to make GCC (and thus SD) happy again with this change reverted/fixed. >>>>> >>>>> Bjorn mentioned offline he is going to take a look, but he has a few >>>>> other things on his plate first. >>>>> >>>> >>>> There is an XO clk created in drivers/clk/qcom/gcc-msm8996.c, we should >>>> do the same here until rpm can handle this. I'll pack this patch up and >>>> merge it to clk-next soon. >>> >>> Thanks. I pulled in the below change into my tree, and fixed up the DT >>> based on the discussion we had. SD works, and things look sane to me >>> per clk_summary in debugfs. >>> >>> Feel free to throw my tested-by on if you want. >> >> Thanks. I did so and merged it up to clk-next. > > @Andy, don't you still need to revert 634da3307b083ee83eb9b377081fdfd6416a148a > ("arm64: dts: qcom: msm8998: correct xo clock name") in for-next? Yes, and no. The SD changes kind of depend on that, so those would need to get sorted as well. I still haven't heard from Andy, but I guess I'll go ahead and create a fixup patch. -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.