[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20170107073059.GV10531@minitux>
Date: Fri, 6 Jan 2017 23:30:59 -0800
From: Bjorn Andersson <bjorn.andersson@...aro.org>
To: Andy Gross <andy.gross@...aro.org>
Cc: John Stultz <john.stultz@...aro.org>,
David Brown <david.brown@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
"linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
linux-soc@...r.kernel.org,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock
On Fri 06 Jan 19:01 PST 2017, Andy Gross wrote:
> On Fri, Jan 06, 2017 at 05:10:44PM -0800, John Stultz wrote:
> > On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
> > <bjorn.andersson@...aro.org> wrote:
> > > As per the device tree binding the apq8064 scm node requires the core
> > > clock to be specified, so add this.
> > >
> > > Cc: John Stultz <john.stultz@...aro.org>
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@...aro.org>
> > > ---
> > > arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > index 268bd470c865..78bf155a52f3 100644
> > > --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> > > @@ -303,6 +303,9 @@
> > > firmware {
> > > scm {
> > > compatible = "qcom,scm-apq8064";
> > > +
> > > + clocks = <&gcc CE3_CORE_CLK>;
> > > + clock-names = "core";
> >
> >
> > Tested-by: John Stultz <john.stultz@...aro.org>
> >
> > I know Bjorn has a new version of this patch that uses the
> > RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
> > usb gadget functionality on my Nexus7. This one seems to work ok
> > though.
>
> Odd. Is the usb gadget using the daytona but not getting a reference? I wonder
> if this is related to not having the bus driver running the bus clk enablement
> and frequencies.
>
The fact that we now reference the Daytona clock means that we're also
telling the RPM to disable it, so that might very well be the case.
Unfortunately I can't find any block diagram for 8064 to show what hangs
off the Daytona, so I'm not sure in what way USB should reference it.
Regards,
Bjorn
Powered by blists - more mailing lists