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;
Date:   Wed, 1 May 2019 09:54:06 -0700
From:   Bjorn Andersson <bjorn.andersson@linaro.org>
To:     Jeffrey Hugo <jhugo@codeaurora.org>
Cc:     mturquette@baylibre.com, sboyd@kernel.org, agross@kernel.org,
        marc.w.gonzalez@free.fr, david.brown@linaro.org,
        robh+dt@kernel.org, mark.rutland@arm.com,
        linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org,
        linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 5/6] clk: qcom: Add MSM8998 Multimedia Clock
 Controller (MMCC) driver
Message-ID: <20190501165406.GI2938@tuxbook-pro>
References: <1556677404-29194-1-git-send-email-jhugo@codeaurora.org>
 <1556677642-29428-1-git-send-email-jhugo@codeaurora.org>
 <20190501034314.GE2938@tuxbook-pro>
 <0513163c-5088-6168-64fb-04fa51f711fa@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0513163c-5088-6168-64fb-04fa51f711fa@codeaurora.org>
User-Agent: Mutt/1.11.4 (2019-03-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed 01 May 07:25 PDT 2019, Jeffrey Hugo wrote:

> On 4/30/2019 9:43 PM, Bjorn Andersson wrote:
> > On Tue 30 Apr 19:27 PDT 2019, Jeffrey Hugo wrote:
> > > +static const struct of_device_id mmcc_msm8998_match_table[] = {
> > > +	{ .compatible = "qcom,mmcc-msm8998" },
> > > +	{ }
> > > +};
> > > +MODULE_DEVICE_TABLE(of, mmcc_msm8998_match_table);
> > > +
> > > +static int mmcc_msm8998_probe(struct platform_device *pdev)
> > > +{
> > > +	struct regmap *regmap;
> > > +
> > 
> > Don't you want to wait for "xo" here as well?
> 
> No, I don't want to.  As far as I recall, Stephen would like to make a clear
> divide between clock providers, and clock consumers.  Since we have the uart
> issue in gcc, and gcc is pretty critical to the entire SoC, it seems like
> there is a reason (not sure I'd call it "good") to wait for xo there.
> 
> Here, I'm less confident in the reasoning.  mmcc is not really critical to
> the SoC, and everything it services is "optional".  If you have a headless
> system with no display output, you won't even need it.  On system where
> there is a display, I expect the realistic driver ordering to be that
> everything which consumes a mmcc clock to come up well after xo is
> available.
> 
> In short, seems like a bit of a kludge to maybe avoid an issue which doesn't
> seem like would happen.
> 

Okay, cool.

> > 
> > > +	regmap = qcom_cc_map(pdev, &mmcc_msm8998_desc);
> > > +	if (IS_ERR(regmap))
> > > +		return PTR_ERR(regmap);
> > > +
> > > +	return qcom_cc_really_probe(pdev, &mmcc_msm8998_desc, regmap);
> > > +}
> > [..]
> > > +MODULE_DESCRIPTION("QCOM MMCC MSM8998 Driver");
> > > +MODULE_LICENSE("GPL v2");
> > > +MODULE_ALIAS("platform:mmcc-msm8998");
> > 
> > MODULE_DEVICE_TABLE() will provide the alias for module auto loading, so
> > drop this.
> 
> Huh.  I did not know that.  Will put on the list to fixup.
> 

With this dropped (and your objection above) I think the patch looks
good.

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> > 
> > Regards,
> > Bjorn
> > 
> 
> 
> -- 
> 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.