Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp5574971ima; Tue, 5 Feb 2019 14:16:41 -0800 (PST) X-Google-Smtp-Source: AHgI3IYdD44ELMGHZokrEY8Y6lIlTjg6dQbXFc4TeHSKSs3QDfV3So5EdcBmB73QTjvkJ2K5fG70 X-Received: by 2002:a63:5b19:: with SMTP id p25mr6619381pgb.424.1549405001860; Tue, 05 Feb 2019 14:16:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549405001; cv=none; d=google.com; s=arc-20160816; b=Gb0ZSh+CibrWes67nTd+4h++s9BIxuLzEJ1w+Q+6oSxO8kzEc6hvOZpkcJ70hdVGeI K8UmR8XfIsWJps7YThLvC6TVmX0gTr2E69mZzgvHGAcsCck5DA4gZPafY3gzT6fKjSOY /rjCrTZpUktLleSgDKcKtDJ5SSdaSXunvX9dhc0aYFb1lIoraUF4LcYsiT14ZG1riDGz aK7W7n/BHvnhS/FrKfj2CYFToqchjWg174oLCLCQ/Tww/c5Njr/KkNDBwjDxYTF81/+S YSiIj19r6fOfCe3naAAI1hpyBUdC8FuFz7ba3/kKPAxfqMJjGTy6NBFIs9Fa8vMPPwg2 JG8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:in-reply-to:to:user-agent:references :cc:message-id:from:subject:content-transfer-encoding:mime-version :dkim-signature; bh=5NvF+VEY0Ys1qLgmtbU7N3JiQOQawkGyqB8uXEEtges=; b=W8qOxVeIe9IvfWVumPe4fOgobosYd36gJVR1xs11/BvP+nMmo0iSyNaHVG7ZcaqzM1 Sx8vfva0ZdQxkscBQ9ysSbSVx0dRlIlcOfMek2LUYg05ZeovaJTJyBV9Hpawx1PO9ker +HTJjT8U+gam7dxMTDxjtZP5xDFmYpZTU5M5rCuKYBOK/rThqnNghMttyV1qvDhFx/RN knrooan5QMYKqif97GKMlxB95SWLZDpq9AUQWTDOveAO0XJGZvNKmIoK2E0hM8pJBd7H BsuL1lStYVYGkqb4niQGRbwqpVGbvwiOjmen5wxcRYi48HV3mwUSi8HSPDMVDs9did16 DvuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=fHpwgn1k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4si414323pgo.41.2019.02.05.14.16.25; Tue, 05 Feb 2019 14:16:41 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=fHpwgn1k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729350AbfBEWQE (ORCPT + 99 others); Tue, 5 Feb 2019 17:16:04 -0500 Received: from mail.kernel.org ([198.145.29.99]:60738 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726742AbfBEWQE (ORCPT ); Tue, 5 Feb 2019 17:16:04 -0500 Received: from localhost (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 5BAFF20823; Tue, 5 Feb 2019 22:16:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549404963; bh=umpQPksptIkOehMreOlU/V5d6V4wOERTvvCniVu/IH0=; h=Subject:From:Cc:References:To:In-Reply-To:Date:From; b=fHpwgn1kOYFXyRd7g/acRnekadp+MshVAaVzAFGpgOmHj7JRoixFHhtshJ2esF4UX yIZ5ZF093htnRA61zrvQSgifMrEvhcmpe8qWbTMSsatYdX9KFVzfINqlIPE8d9opRT vWakjWimk9TpxzeUBi02Wsbq60fE4RFEwfdmwDN0= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH v1 2/4] dt-bindings: clock: Add support for the MSM8998 mmcc From: Stephen Boyd Message-ID: <154940496255.169292.11279175475668034167@swboyd.mtv.corp.google.com> Cc: marc.w.gonzalez@free.fr, andy.gross@linaro.org, david.brown@linaro.org, linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org References: <1548866102-30224-1-git-send-email-jhugo@codeaurora.org> <1548866159-30304-1-git-send-email-jhugo@codeaurora.org> <154940414347.169292.9150834270087697417@swboyd.mtv.corp.google.com> User-Agent: alot/0.8 To: Jeffrey Hugo , bjorn.andersson@linaro.org, mark.rutland@arm.com, mturquette@baylibre.com, robh+dt@kernel.org In-Reply-To: Date: Tue, 05 Feb 2019 14:16:02 -0800 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Jeffrey Hugo (2019-02-05 14:08:43) > On 2/5/2019 3:02 PM, Stephen Boyd wrote: > > Quoting Jeffrey Hugo (2019-01-30 08:35:59) > >> Document the multimedia clock controller found on MSM8998 > >> > >> Signed-off-by: Jeffrey Hugo > >> --- > >> Documentation/devicetree/bindings/clock/qcom,mmcc.txt | 7 +++++++ > >> 1 file changed, 7 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/D= ocumentation/devicetree/bindings/clock/qcom,mmcc.txt > >> index 8b0f784..ae85bca 100644 > >> --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt > >> +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt > >> @@ -10,11 +10,18 @@ Required properties : > >> "qcom,mmcc-msm8960" > >> "qcom,mmcc-msm8974" > >> "qcom,mmcc-msm8996" > >> + "qcom,mmcc-msm8998" > >> =20 > >> - reg : shall contain base register location and length > >> - #clock-cells : shall contain 1 > >> - #reset-cells : shall contain 1 > >> =20 > >> +For MSM8998 only: > >> + - clocks: a list of phandles and clock-specifier pairs, > >> + one for each entry in clock-names. > >> + - clock-names: "xo" for the xo clock, > >> + "gpll0" for the global pll 0 clock. > >=20 > > Wouldn't the DSI plls also be listed here? And anything else that is > > external to this clock controller? > >=20 >=20 > We can't get the DSI plls from DT as far as I am aware (upstream). That = > is why I mentioned in the cover letter we need to rely on the global=20 > namespace. Why not? Because the DSI PLL isn't a clk provider? Or it doesn't have #clock-cells? Please try to use the DSI PLLs from DT or at least specify them in the binding as optional clocks that may not matter if DSI is not enabled for example. >=20 > Also, the DSI plls, etc present a chicken and egg situation, as the plls = > require mmcc, and mmcc requires the plls. I forsee an unsolvable=20 > EPROBE_DEFER issue. >=20 We've "solved" that problem with orphan clks and the clk parent rewrite series. Maybe you can try it out to help flush out any bugs lurking there.