| Message ID | 1383343739-23080-3-git-send-email-sboyd@codeaurora.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: > From: Rohit Vaswani <rvaswani@codeaurora.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@vger.kernel.org> > Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> > [sboyd: Split off into separate patch, renamed method to > qcom,mmio] > Signed-off-by: Stephen Boyd <sboyd@codeaurora.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? Rob
On 11/01, Rob Herring wrote: > On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: > > From: Rohit Vaswani <rvaswani@codeaurora.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@vger.kernel.org> > > Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> > > [sboyd: Split off into separate patch, renamed method to > > qcom,mmio] > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.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.
On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote: > On 11/01, Rob Herring wrote: >> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: >>> From: Rohit Vaswani <rvaswani@codeaurora.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@vger.kernel.org> >>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> >>> [sboyd: Split off into separate patch, renamed method to >>> qcom,mmio] >>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.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. I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'. It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'. - k
On 11/05/13 09:12, Kumar Gala wrote: > On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote: > >> On 11/01, Rob Herring wrote: >>> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: >>>> From: Rohit Vaswani <rvaswani@codeaurora.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@vger.kernel.org> >>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> >>>> [sboyd: Split off into separate patch, renamed method to >>>> qcom,mmio] >>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.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. > > I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'. It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'. > Do you have any reasons why? I don't see why we need to keep adding more and more enable-methods every time the subsystem surrounding the CPU changes. The method is the same, write some registers to power up the CPU for the first time (cold boot) or ping the CPU to wake it up (warmboot). The only difference is where those registers live and a slight variation in the sequence that we perform.
On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote: > On 11/05/13 09:12, Kumar Gala wrote: >> On Nov 4, 2013, at 11:36 AM, Stephen Boyd wrote: >> >>> On 11/01, Rob Herring wrote: >>>> On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote: >>>>> From: Rohit Vaswani <rvaswani@codeaurora.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@vger.kernel.org> >>>>> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org> >>>>> [sboyd: Split off into separate patch, renamed method to >>>>> qcom,mmio] >>>>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.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. >> >> I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'. It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'. >> > > Do you have any reasons why? I don't see why we need to keep adding more > and more enable-methods every time the subsystem surrounding the CPU > changes. The method is the same, write some registers to power up the > CPU for the first time (cold boot) or ping the CPU to wake it up > (warmboot). The only difference is where those registers live and a > slight variation in the sequence that we perform. By that argument every device could just be compatible with 'mmio' and be done with it ;) As the registers you write vary, the compatible should vary. - k
On 11/05/13 09:43, Kumar Gala wrote: > On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote: > >> On 11/05/13 09:12, Kumar Gala wrote: >>> I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'. It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'. >>> >> Do you have any reasons why? I don't see why we need to keep adding more >> and more enable-methods every time the subsystem surrounding the CPU >> changes. The method is the same, write some registers to power up the >> CPU for the first time (cold boot) or ping the CPU to wake it up >> (warmboot). The only difference is where those registers live and a >> slight variation in the sequence that we perform. > By that argument every device could just be compatible with 'mmio' and be done with it ;) > > As the registers you write vary, the compatible should vary. The compatible does vary. The enable-method is not a compatible property.
On Nov 5, 2013, at 11:46 AM, Stephen Boyd wrote: > On 11/05/13 09:43, Kumar Gala wrote: >> On Nov 5, 2013, at 11:35 AM, Stephen Boyd wrote: >> >>> On 11/05/13 09:12, Kumar Gala wrote: >>>> I think this should be more specific than just 'qcom,mmio' or 'qcom,warm-boot'. It should be 'qcom,kpss-acc-v1' or 'qcom-gcc-8660'. >>>> >>> Do you have any reasons why? I don't see why we need to keep adding more >>> and more enable-methods every time the subsystem surrounding the CPU >>> changes. The method is the same, write some registers to power up the >>> CPU for the first time (cold boot) or ping the CPU to wake it up >>> (warmboot). The only difference is where those registers live and a >>> slight variation in the sequence that we perform. >> By that argument every device could just be compatible with 'mmio' and be done with it ;) >> >> As the registers you write vary, the compatible should vary. > > The compatible does vary. The enable-method is not a compatible property. > > -- I've always felt that the enable-method is equivalent of a compatible property. - k
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" Example: