[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131104173606.GL21983@codeaurora.org>
Date: Mon, 4 Nov 2013 09:36:06 -0800
From: Stephen Boyd <sboyd@...eaurora.org>
To: Rob Herring <robherring2@...il.com>
Cc: "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
David Brown <davidb@...eaurora.org>,
Rohit Vaswani <rvaswani@...eaurora.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and
enable-method
On 11/01, Rob Herring wrote:
> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> > From: Rohit Vaswani <rvaswani@...eaurora.org>
> >
> > Scorpion and Krait are Qualcomm cpus. These cpus don't use the
> > spin-table enable-method. Instead they rely on mmio register
> > accesses to enable power and clocks to bring CPUs out of reset.
> >
> > Cc: <devicetree@...r.kernel.org>
> > Signed-off-by: Rohit Vaswani <rvaswani@...eaurora.org>
> > [sboyd: Split off into separate patch, renamed method to
> > qcom,mmio]
> > Signed-off-by: Stephen Boyd <sboyd@...eaurora.org>
> > ---
> >
> > This slightly conflicts with my krait EDAC series.
> >
> > Documentation/devicetree/bindings/arm/cpus.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
> > index 37258f9..e2969fa2 100644
> > --- a/Documentation/devicetree/bindings/arm/cpus.txt
> > +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> > @@ -44,6 +44,8 @@ For the ARM architecture every CPU node must contain the following properties:
> > "marvell,mohawk"
> > "marvell,xsc3"
> > "marvell,xscale"
> > + "qcom,scorpion"
> > + "qcom,krait"
> >
> > And the following optional properties:
> >
> > @@ -52,6 +54,7 @@ And the following optional properties:
> > different types of cpus.
> > This should be one of:
> > "spin-table"
> > + "qcom,mmio"
>
> Not exactly specific. How would you handle variations in the enable
> method? The mmio method to enable is tied to the core type or SOC
> type?
Variations in the enable method are handled by searching for
another node with different compatible strings. Later on in this
series you'll see that we search for gcc-8660, kpss-acc-v1, or
kpps-acc-v2. Once we find one of these nodes we perform the
correct cold boot routine.
I'm actually considering renaming this to "qcom,cold-boot". We
could further extend the enable-metho property to allow
"qcom,warm-boot" and then for cases like kexec we could make the
enable method be warm boot and our smp code could be smart enough
to know to skip the whole cold boot sequence.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists