[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200820104540.4c4cg4rn4oa4rh6t@vireshk-i7>
Date: Thu, 20 Aug 2020 16:15:40 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Stephen Boyd <swboyd@...omium.org>
Cc: Rajendra Nayak <rnayak@...eaurora.org>, agross@...nel.org,
bjorn.andersson@...aro.org, robdclark@...omium.org,
robdclark@...il.com, stanimir.varbanov@...aro.org,
mka@...omium.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Akash Asthana <akashast@...eaurora.org>,
linux-serial@...r.kernel.org
Subject: Re: [PATCH v6 1/6] tty: serial: qcom_geni_serial: Use OPP API to set
clk/perf state
On 22-07-20, 10:54, Viresh Kumar wrote:
> On 21-07-20, 01:43, Stephen Boyd wrote:
> > It seems that dev_pm_opp_set_rate() calls _find_opp_table() and finds
> > something that isn't an error pointer but then dev_pm_opp_of_add_table()
> > returns an error value because there isn't an operating-points property
> > in DT. We're getting saved because this driver also happens to call
> > dev_pm_opp_set_clkname() which allocates the OPP table a second time
> > (because the first time it got freed when dev_pm_opp_of_add_table()
> > return -ENODEV because the property was missing).
> >
> > Why do we need 'has_opp_table' logic? It seems that we have to keep
> > track of the fact that dev_pm_opp_of_add_table() failed so that we don't
> > put the table again, but then dev_pm_opp_set_clkname() can be called
> > to allocate the table regardless.
I have sent a patchset to clean this stuff up a bit now.
--
viresh
Powered by blists - more mailing lists