[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181114222443.GL22824@google.com>
Date: Wed, 14 Nov 2018 14:24:43 -0800
From: Matthias Kaehlcke <mka@...omium.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: David Airlie <airlied@...ux.ie>,
Mark Rutland <mark.rutland@....com>,
Rob Clark <robdclark@...il.com>,
Rob Herring <robh+dt@...nel.org>,
Archit Taneja <architt@...eaurora.org>,
Sean Paul <seanpaul@...omium.org>,
Rajesh Yadav <ryadav@...eaurora.org>,
Douglas Anderson <dianders@...omium.org>,
linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/msm/dsi: Get PHY ref clock from the DT
On Tue, Nov 06, 2018 at 03:11:48PM -0800, Stephen Boyd wrote:
> Quoting Matthias Kaehlcke (2018-11-02 14:45:34)
> > @@ -630,7 +632,8 @@ static int pll_10nm_register(struct dsi_pll_10nm *pll_10nm)
> > char clk_name[32], parent[32], vco_name[32];
> > char parent2[32], parent3[32], parent4[32];
> > struct clk_init_data vco_init = {
> > - .parent_names = (const char *[]){ "xo" },
> > + .parent_names = (const char *[]){
> > + __clk_get_name(pll_10nm->vco_ref_clk) },
>
> I find this syntax odd, in addition to needing to check for NULL here as
> Sean pointed out. Preferably just have it be the address of the
> character pointer instead of making an anonymous array and then casting
> that inline, i.e
>
> .parent_names = &ref_clk_name,
Ok
I'm not convinced the check for NULL is needed though, see my reply to Sean.
> > .num_parents = 1,
> > .name = vco_name,
> > .flags = CLK_IGNORE_UNUSED,
> > @@ -786,6 +789,12 @@ struct msm_dsi_pll *msm_dsi_pll_10nm_init(struct platform_device *pdev, int id)
> > pll_10nm->id = id;
> > pll_10nm_list[id] = pll_10nm;
> >
> > + pll_10nm->vco_ref_clk = devm_clk_get(&pdev->dev, "ref");
> > + if (IS_ERR(pll_10nm->vco_ref_clk)) {
> > + dev_err(&pdev->dev, "couldn't get 'ref' clock\n");
>
> This might be because of probe defer, which may be annoying to see this
> failure many times.
Ok, will skip the logging for -EPROBE_DEFER
Cheers
Matthias
Powered by blists - more mailing lists