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@xxxxxxxxxx> 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@xxxxxxxxxx>
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > > ---
> > > 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@xxxxxxxxxx>
> >
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
