linux-kernel - Re: [PATCH v4 0/2] clk: qcom: Add support for RCG to register for DFS

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <153540388675.129321.14679244317392825384@swboyd.mtv.corp.google.com>
Date:   Mon, 27 Aug 2018 14:04:46 -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 v4 0/2] clk: qcom: Add support for RCG to register for DFS

Quoting Stephen Boyd (2018-08-23 11:25:41)
> Quoting Taniya Das (2018-08-22 03:28:31)
> > 
> > > 
> > > Hmmmm. Ok. That won't work then. recalc_rate() better not try to
> > > populate the frequency table then or it will not work. So I suppose it
> > > needs to fallback to reading the registers and assuming the parent_rate
> > > coming in is the actual frequency of it's parent until the frequency
> > > table pointer is non-NULL. Would that work?
> > > 
> > Yes that would work.
> 
> Ok.
> 
> > 
> > > BTW, does DFS switch parents without software knowing about it? 
> > DFS would not switch until a HW request is sent, but SW would be unware 
> > of the switch except the current_perf_state being updated with the 
> > requested level.
> > 
> > What
> > > happens in that case? Does the QUP driver make sure that the new parent
> > > of this RCG is properly enabled so that it can switch to it when needed?
> > 
> > I am not sure if they poll for any of their QUP HW state to make sure 
> > the switch is complete.
> > 
> > > I'm still trying to understand this whole design. Who takes care of the
> > > voltage requirements in this case? The QUP driver as well?
> > > 
> > 
> > When the QUP driver requires to switch to new performance level, the 
> > first request would be to set_rate()(QUP driver would get the list of 
> > supported frequencies using the clk_round_rate()) which in QCOM clock 
> > driver would take care of setting the required voltage for the new 
> > parent switch.
> 
> It would also make sure that the new parent is enabled if the QUP clk is
> enabled. That's another concern. Does the PLL turn on automatically when
> the RCG switches to it?
> 
> > Then the QUP driver would request the HW for a new perf switch which 
> > would result to a DFS switch for the QUP clocks.
> 
> It sounds like the QUP driver does half of the work via the clk APIs and
> then the other half through the DFS register. Maybe the QUP driver
> should be registering a clk as well for its DFS register so it can all
> be clk API calls here. Something to consider. Anyway, that's not
> important to this patch so here's the updated patch.

I've squashed this in and applied the patches.