[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <153114876561.143105.465317097490450694@swboyd.mtv.corp.google.com>
Date: Mon, 09 Jul 2018 08:06:05 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Michael Turquette <mturquette@...libre.com>,
Taniya Das <tdas@...eaurora.org>
Cc: Andy Gross <andy.gross@...aro.org>,
David Brown <david.brown@...aro.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
Amit Nischal <anischal@...eaurora.org>,
linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/3] clk: qcom: Add display clock controller driver for SDM845
Quoting Taniya Das (2018-07-09 02:34:07)
>
>
> On 7/9/2018 1:07 PM, Stephen Boyd wrote:
> > Quoting Taniya Das (2018-07-09 00:07:21)
> >>
> >>
> >> On 7/9/2018 11:46 AM, Stephen Boyd wrote:
> >>>>
> >>>> > Why is the nocache flag needed? Applies to all clks in this file.
> >>>> >
> >>>>
> >>>> This flag is required for all RCGs whose PLLs are controlled outside the
> >>>> clock controller. The display code would require the recalculated rate
> >>>> always.
> >>>
> >>> Right. Why is the PLL controlled outside of the clock controller? The
> >>> rate should propagate upward to the PLL from here, so who's going
> >>> outside of that?
> >>>
> >> The DSI0/1 PLL are not part of the display clock controller, but in the
> >> display subsystem which are managed by the DRM drivers. When DRM drivers
> >> query for the rate clock driver should always return the non cached rates.
> >
> > Why? Is the DSI PLL changing rate all the time, randomly, without going
> > through the clk APIs to do so?
> >
>
> Hmm, I am afraid I do not have an answer for this, but this was the
> requirement to always return the non cached rates from the clock driver.
>
Ok. Who knows about this requirement? Can we add someone from the
display driver to understand more?
Powered by blists - more mailing lists