* [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
2013-11-02 1:00 ` Rob Herring
2013-11-08 9:12 ` Tomasz Figa
2013-11-01 22:08 ` [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method Stephen Boyd
` (3 subsequent siblings)
4 siblings, 2 replies; 25+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree,
linux-kernel
From: Rohit Vaswani <rvaswani@codeaurora.org>
According to the ePAPR CPUs should have an enable method. On ARM
the enable-method property has not been used so far, so document
this property as an optional property and add the spin-table
method as one value
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
[sboyd: Split off into separate patch]
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
Documentation/devicetree/bindings/arm/cpus.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494d..37258f9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -45,6 +45,14 @@ For the ARM architecture every CPU node must contain the following properties:
"marvell,xsc3"
"marvell,xscale"
+And the following optional properties:
+
+- enable-method: Specifies the method used to enable or take the secondary cores
+ out of reset. This allows different reset sequence for
+ different types of cpus.
+ This should be one of:
+ "spin-table"
+
Example:
cpus {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 ` [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs Stephen Boyd
@ 2013-11-02 1:00 ` Rob Herring
2013-11-08 9:12 ` Tomasz Figa
1 sibling, 0 replies; 25+ messages in thread
From: Rob Herring @ 2013-11-02 1:00 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel@lists.infradead.org, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
On Fri, Nov 1, 2013 at 5:08 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> From: Rohit Vaswani <rvaswani@codeaurora.org>
>
> According to the ePAPR CPUs should have an enable method. On ARM
> the enable-method property has not been used so far, so document
> this property as an optional property and add the spin-table
> method as one value
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Split off into separate patch]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs
2013-11-01 22:08 ` [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs Stephen Boyd
2013-11-02 1:00 ` Rob Herring
@ 2013-11-08 9:12 ` Tomasz Figa
1 sibling, 0 replies; 25+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:12 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Stephen Boyd, linux-arm-msm, David Brown, Rohit Vaswani,
devicetree, linux-kernel
On Friday 01 of November 2013 15:08:49 Stephen Boyd wrote:
> From: Rohit Vaswani <rvaswani@codeaurora.org>
>
> According to the ePAPR CPUs should have an enable method. On ARM
> the enable-method property has not been used so far, so document
> this property as an optional property and add the spin-table
> method as one value
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
> [sboyd: Split off into separate patch]
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> Documentation/devicetree/bindings/arm/cpus.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/cpus.txt
> b/Documentation/devicetree/bindings/arm/cpus.txt index f32494d..37258f9
> 100644
> --- a/Documentation/devicetree/bindings/arm/cpus.txt
> +++ b/Documentation/devicetree/bindings/arm/cpus.txt
> @@ -45,6 +45,14 @@ For the ARM architecture every CPU node must contain
> the following properties: "marvell,xsc3"
> "marvell,xscale"
>
> +And the following optional properties:
> +
> +- enable-method: Specifies the method used to enable or take the
> secondary cores + out of reset. This allows different reset
sequence
> for
> + different types of cpus.
> + This should be one of:
> + "spin-table"
What about saying a word or two (other than property value) about each
method?
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
2013-11-01 22:08 ` [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
2013-11-02 1:04 ` Rob Herring
2013-11-01 22:08 ` [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc Stephen Boyd
` (2 subsequent siblings)
4 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree,
linux-kernel
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"
Example:
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-01 22:08 ` [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method Stephen Boyd
@ 2013-11-02 1:04 ` Rob Herring
2013-11-04 17:36 ` Stephen Boyd
0 siblings, 1 reply; 25+ messages in thread
From: Rob Herring @ 2013-11-02 1:04 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel@lists.infradead.org, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-02 1:04 ` Rob Herring
@ 2013-11-04 17:36 ` Stephen Boyd
2013-11-05 17:12 ` Kumar Gala
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-04 17:36 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel@lists.infradead.org, linux-arm-msm, David Brown,
Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-04 17:36 ` Stephen Boyd
@ 2013-11-05 17:12 ` Kumar Gala
2013-11-05 17:35 ` Stephen Boyd
0 siblings, 1 reply; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel@lists.infradead.org, linux-arm-msm,
David Brown, Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:12 ` Kumar Gala
@ 2013-11-05 17:35 ` Stephen Boyd
2013-11-05 17:43 ` Kumar Gala
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:35 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel@lists.infradead.org, linux-arm-msm,
David Brown, Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:35 ` Stephen Boyd
@ 2013-11-05 17:43 ` Kumar Gala
2013-11-05 17:46 ` Stephen Boyd
0 siblings, 1 reply; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:43 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel@lists.infradead.org, linux-arm-msm,
David Brown, Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:43 ` Kumar Gala
@ 2013-11-05 17:46 ` Stephen Boyd
2013-11-05 18:12 ` Kumar Gala
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:46 UTC (permalink / raw)
To: Kumar Gala
Cc: Rob Herring, linux-arm-kernel@lists.infradead.org, linux-arm-msm,
David Brown, Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method
2013-11-05 17:46 ` Stephen Boyd
@ 2013-11-05 18:12 ` Kumar Gala
0 siblings, 0 replies; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 18:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Rob Herring, linux-arm-kernel@lists.infradead.org, linux-arm-msm,
David Brown, Rohit Vaswani, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
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
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
2013-11-01 22:08 ` [PATCH 01/11] devicetree: bindings: Document cpu enable-method for ARM CPUs Stephen Boyd
2013-11-01 22:08 ` [PATCH 02/11] devicetree: bindings: Document Qualcomm cpus and enable-method Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:13 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node Stephen Boyd
2013-11-01 22:08 ` [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp Stephen Boyd
4 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-arm-msm, David Brown, Rohit Vaswani, devicetree,
linux-kernel
The kpss acc binding describes the clock, reset, and power domain
controller for a Krait CPU.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
.../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
new file mode 100644
index 0000000..ed4a9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
@@ -0,0 +1,21 @@
+* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
+
+The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+There is one ACC register region per CPU within the KPSS remaped region as
+well as an alias register region that remaps accesses to the ACC associated
+with the CPU accessing the region.
+
+Required Properties:
+
+- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
+- reg: Specifies the base address and size of the banked register region.
+- cpu-offset : per-cpu offset used when the device is accessed without the
+ CPU remapping facilities.
+ The offset is cpu-offset + (0x10000 * cpu-nr).
+
+Example:
+
+ clock-controller@2008000 {
+ compatible = "qcom,kpss-acc-v2";
+ reg = <0x02008000 0x1000>;
+ };
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-01 22:08 ` [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc Stephen Boyd
@ 2013-11-05 17:13 ` Kumar Gala
2013-11-05 17:44 ` Stephen Boyd
0 siblings, 1 reply; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:13 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
> The kpss acc binding describes the clock, reset, and power domain
> controller for a Krait CPU.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> .../devicetree/bindings/arm/msm/qcom,kpss-acc.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> new file mode 100644
> index 0000000..ed4a9c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> @@ -0,0 +1,21 @@
> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
> +
> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
> +There is one ACC register region per CPU within the KPSS remaped region as
> +well as an alias register region that remaps accesses to the ACC associated
> +with the CPU accessing the region.
> +
> +Required Properties:
> +
> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
> +- reg: Specifies the base address and size of the banked register region.
> +- cpu-offset : per-cpu offset used when the device is accessed without the
> + CPU remapping facilities.
> + The offset is cpu-offset + (0x10000 * cpu-nr).
> +
> +Example:
> +
> + clock-controller@2008000 {
> + compatible = "qcom,kpss-acc-v2";
> + reg = <0x02008000 0x1000>;
> + };
> --
I don't get the cpu-offset business, shouldn't this just be:
reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:13 ` Kumar Gala
@ 2013-11-05 17:44 ` Stephen Boyd
2013-11-05 17:51 ` Kumar Gala
0 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:44 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
On 11/05/13 09:13, Kumar Gala wrote:
> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>
>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> new file mode 100644
>> index 0000000..ed4a9c8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>> @@ -0,0 +1,21 @@
>> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
>> +
>> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
>> +There is one ACC register region per CPU within the KPSS remaped region as
>> +well as an alias register region that remaps accesses to the ACC associated
>> +with the CPU accessing the region.
>> +
>> +Required Properties:
>> +
>> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
>> +- reg: Specifies the base address and size of the banked register region.
>> +- cpu-offset : per-cpu offset used when the device is accessed without the
>> + CPU remapping facilities.
>> + The offset is cpu-offset + (0x10000 * cpu-nr).
>> +
>> +Example:
>> +
>> + clock-controller@2008000 {
>> + compatible = "qcom,kpss-acc-v2";
>> + reg = <0x02008000 0x1000>;
>> + };
>> --
> I don't get the cpu-offset business, shouldn't this just be:
> reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;
>
(Sorry I forgot to add the cpu-offset to the example.)
Your reg property is one way to do it. I was following the example of
the GIC binding which just specifies the alias region of the GIC's CPU
registers and then has a cpu-offset property to describe how to reach a
specific CPU's region.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:44 ` Stephen Boyd
@ 2013-11-05 17:51 ` Kumar Gala
2013-11-08 9:10 ` Tomasz Figa
0 siblings, 1 reply; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:51 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
On Nov 5, 2013, at 11:44 AM, Stephen Boyd wrote:
> On 11/05/13 09:13, Kumar Gala wrote:
>> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>>
>>> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>> new file mode 100644
>>> index 0000000..ed4a9c8
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>> @@ -0,0 +1,21 @@
>>> +* Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
>>> +
>>> +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
>>> +There is one ACC register region per CPU within the KPSS remaped region as
>>> +well as an alias register region that remaps accesses to the ACC associated
>>> +with the CPU accessing the region.
>>> +
>>> +Required Properties:
>>> +
>>> +- compatible : Shall contain "qcom,kpss-acc-v1" or "qcom,kpss-acc-v2".
>>> +- reg: Specifies the base address and size of the banked register region.
>>> +- cpu-offset : per-cpu offset used when the device is accessed without the
>>> + CPU remapping facilities.
>>> + The offset is cpu-offset + (0x10000 * cpu-nr).
>>> +
>>> +Example:
>>> +
>>> + clock-controller@2008000 {
>>> + compatible = "qcom,kpss-acc-v2";
>>> + reg = <0x02008000 0x1000>;
>>> + };
>>> --
>> I don't get the cpu-offset business, shouldn't this just be:
>> reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000 0x1000>, <0x02038000 0x1000>;
>>
>
> (Sorry I forgot to add the cpu-offset to the example.)
>
> Your reg property is one way to do it. I was following the example of
> the GIC binding which just specifies the alias region of the GIC's CPU
> registers and then has a cpu-offset property to describe how to reach a
> specific CPU's region.
Even in the gic's case I think we should have the reg property cover the memory map.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-05 17:51 ` Kumar Gala
@ 2013-11-08 9:10 ` Tomasz Figa
2013-11-08 14:30 ` Kumar Gala
0 siblings, 1 reply; 25+ messages in thread
From: Tomasz Figa @ 2013-11-08 9:10 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kumar Gala, Stephen Boyd, devicetree, linux-arm-msm,
Rohit Vaswani, linux-kernel, David Brown
On Tuesday 05 of November 2013 11:51:07 Kumar Gala wrote:
> On Nov 5, 2013, at 11:44 AM, Stephen Boyd wrote:
> > On 11/05/13 09:13, Kumar Gala wrote:
> >> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> >>> b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new
> >>> file mode 100644
> >>> index 0000000..ed4a9c8
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
> >>> @@ -0,0 +1,21 @@
> >>> +* Krait Processor Sub-system (KPSS) Application Clock Controller
> >>> (ACC)
> >>> +
> >>> +The KPSS ACC provides clock, power domain, and reset control to a
> >>> Krait CPU. +There is one ACC register region per CPU within the
> >>> KPSS remaped region as +well as an alias register region that
> >>> remaps accesses to the ACC associated +with the CPU accessing the
> >>> region.
> >>> +
> >>> +Required Properties:
> >>> +
> >>> +- compatible : Shall contain "qcom,kpss-acc-v1" or
> >>> "qcom,kpss-acc-v2".
> >>> +- reg: Specifies the base address and size of the banked register
> >>> region. +- cpu-offset : per-cpu offset used when the device is
> >>> accessed without the + CPU remapping facilities.
> >>> + The offset is cpu-offset + (0x10000 * cpu-nr).
> >>> +
> >>> +Example:
> >>> +
> >>> + clock-controller@2008000 {
> >>> + compatible = "qcom,kpss-acc-v2";
> >>> + reg = <0x02008000 0x1000>;
> >>> + };
> >>
> >> I don't get the cpu-offset business, shouldn't this just be:
> >> reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000
0x1000>,
> >> <0x02038000 0x1000>;>
> > (Sorry I forgot to add the cpu-offset to the example.)
> >
> > Your reg property is one way to do it. I was following the example of
> > the GIC binding which just specifies the alias region of the GIC's CPU
> > registers and then has a cpu-offset property to describe how to reach
> > a
> > specific CPU's region.
>
> Even in the gic's case I think we should have the reg property cover the
> memory map.
The GIC case was supposed to be a hack for Exynos SoCs that do not have
banked per-CPU registers. Currently I consider it broken, because it does
not scale for multi cluster configurations. I believe you should consider
the same.
IMHO the way to provide per-CPU properties should involve CPU nodes to
make sure that the same CPU ID namespace is always used.
Best regards,
Tomasz
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc
2013-11-08 9:10 ` Tomasz Figa
@ 2013-11-08 14:30 ` Kumar Gala
0 siblings, 0 replies; 25+ messages in thread
From: Kumar Gala @ 2013-11-08 14:30 UTC (permalink / raw)
To: Tomasz Figa
Cc: linux-arm-kernel, Stephen Boyd, devicetree, linux-arm-msm,
Rohit Vaswani, linux-kernel, David Brown
On Nov 8, 2013, at 3:10 AM, Tomasz Figa wrote:
> On Tuesday 05 of November 2013 11:51:07 Kumar Gala wrote:
>> On Nov 5, 2013, at 11:44 AM, Stephen Boyd wrote:
>>> On 11/05/13 09:13, Kumar Gala wrote:
>>>> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>>>>> diff --git
>>>>> a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>>>> b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new
>>>>> file mode 100644
>>>>> index 0000000..ed4a9c8
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
>>>>> @@ -0,0 +1,21 @@
>>>>> +* Krait Processor Sub-system (KPSS) Application Clock Controller
>>>>> (ACC)
>>>>> +
>>>>> +The KPSS ACC provides clock, power domain, and reset control to a
>>>>> Krait CPU. +There is one ACC register region per CPU within the
>>>>> KPSS remaped region as +well as an alias register region that
>>>>> remaps accesses to the ACC associated +with the CPU accessing the
>>>>> region.
>>>>> +
>>>>> +Required Properties:
>>>>> +
>>>>> +- compatible : Shall contain "qcom,kpss-acc-v1" or
>>>>> "qcom,kpss-acc-v2".
>>>>> +- reg: Specifies the base address and size of the banked register
>>>>> region. +- cpu-offset : per-cpu offset used when the device is
>>>>> accessed without the + CPU remapping facilities.
>>>>> + The offset is cpu-offset + (0x10000 * cpu-nr).
>>>>> +
>>>>> +Example:
>>>>> +
>>>>> + clock-controller@2008000 {
>>>>> + compatible = "qcom,kpss-acc-v2";
>>>>> + reg = <0x02008000 0x1000>;
>>>>> + };
>>>>
>>>> I don't get the cpu-offset business, shouldn't this just be:
>>>> reg = <0x02008000 0x1000>, <0x02018000 0x1000>, <0x02028000
> 0x1000>,
>>>> <0x02038000 0x1000>;>
>>> (Sorry I forgot to add the cpu-offset to the example.)
>>>
>>> Your reg property is one way to do it. I was following the example of
>>> the GIC binding which just specifies the alias region of the GIC's CPU
>>> registers and then has a cpu-offset property to describe how to reach
>>> a
>>> specific CPU's region.
>>
>> Even in the gic's case I think we should have the reg property cover the
>> memory map.
>
> The GIC case was supposed to be a hack for Exynos SoCs that do not have
> banked per-CPU registers. Currently I consider it broken, because it does
> not scale for multi cluster configurations. I believe you should consider
> the same.
>
> IMHO the way to provide per-CPU properties should involve CPU nodes to
> make sure that the same CPU ID namespace is always used.
>
> Best regards,
> Tomasz
Yeah, Stephen and I talked off line about it and I think we'll end up with a bit of both. Having the reg property describe both regions, as well as having some nodes via the CPU node to get to the proper "device" for that cpu.
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
` (2 preceding siblings ...)
2013-11-01 22:08 ` [PATCH 03/11] devicetree: bindings: Document qcom,kpss-acc Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:16 ` Kumar Gala
2013-11-01 22:08 ` [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp Stephen Boyd
4 siblings, 1 reply; 25+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm,
devicetree
The saw2 binding describes the SPM/AVS wrapper hardware used to
control the regulator supplying voltage to the Krait CPUs.
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
When a SAW is for a CPU it is put behind the CPU alias region similar
to the ACC and timers. I haven't documented that here because I'm not using
it right now. I'm also thinking perhaps l2-saw2 is not important (technically
its the same hardware block as a CPU's saw). Instead I should point to this
node via the l2-cache node via some *-supply property. Thoughts?
.../devicetree/bindings/arm/msm/qcom,saw2.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
new file mode 100644
index 0000000..6360db2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -0,0 +1,23 @@
+* SPM AVS Wrapper 2 (SAW2)
+
+The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
+Adaptive Voltage Scaling (AVS) hardware. The SPM is programmable
+micro-controller that transitions a piece of hardware (like a processor) into
+and out of low power modes via a direct connection to the PMIC. It can also
+be wired up to interact with other processors in the system, notifying them
+when a low power state is entered or exited.
+
+Required Properties:
+
+- compatible : Shall contain "qcom,saw2".
+ A more specific property can be specified as follows:
+ "qcom,l2-saw2"
+- reg: Specifies the base address and size of the register region.
+
+Example:
+
+ regulator@f9012000 {
+ compatible = "qcom,l2-saw2", "qcom,saw2";
+ reg = <0xf9012000 0x1000>;
+ };
+
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node
2013-11-01 22:08 ` [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node Stephen Boyd
@ 2013-11-05 17:16 ` Kumar Gala
0 siblings, 0 replies; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:16 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, devicetree
On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
> The saw2 binding describes the SPM/AVS wrapper hardware used to
> control the regulator supplying voltage to the Krait CPUs.
>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
>
> When a SAW is for a CPU it is put behind the CPU alias region similar
> to the ACC and timers. I haven't documented that here because I'm not using
> it right now. I'm also thinking perhaps l2-saw2 is not important (technically
> its the same hardware block as a CPU's saw). Instead I should point to this
> node via the l2-cache node via some *-supply property. Thoughts?
I don't get this, why wouldn't the SAW just be under the soc node? Do we really need to encode a relationship between the cpu and the SAW?
And kill the "l2-saw2" stuff until its needed.
Also are SAWs specific to a given SoC or not?
>
> .../devicetree/bindings/arm/msm/qcom,saw2.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
> new file mode 100644
> index 0000000..6360db2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
> @@ -0,0 +1,23 @@
> +* SPM AVS Wrapper 2 (SAW2)
> +
> +The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
> +Adaptive Voltage Scaling (AVS) hardware. The SPM is programmable
> +micro-controller that transitions a piece of hardware (like a processor) into
> +and out of low power modes via a direct connection to the PMIC. It can also
> +be wired up to interact with other processors in the system, notifying them
> +when a low power state is entered or exited.
> +
> +Required Properties:
> +
> +- compatible : Shall contain "qcom,saw2".
> + A more specific property can be specified as follows:
> + "qcom,l2-saw2"
> +- reg: Specifies the base address and size of the register region.
> +
> +Example:
> +
> + regulator@f9012000 {
> + compatible = "qcom,l2-saw2", "qcom,saw2";
> + reg = <0xf9012000 0x1000>;
> + };
> +
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-01 22:08 [PATCH 00/11] CPU enable method based SMP/hotplug + MSM conversion Stephen Boyd
` (3 preceding siblings ...)
2013-11-01 22:08 ` [PATCH 04/11] devicetree: bindings: Document qcom,saw2 node Stephen Boyd
@ 2013-11-01 22:08 ` Stephen Boyd
2013-11-05 17:24 ` Kumar Gala
[not found] ` <1383343739-23080-6-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
4 siblings, 2 replies; 25+ messages in thread
From: Stephen Boyd @ 2013-11-01 22:08 UTC (permalink / raw)
To: linux-arm-kernel
Cc: David Brown, Rohit Vaswani, linux-kernel, linux-arm-msm,
Mark Rutland, Russell King, devicetree
The goal of multi-platform kernels is to remove the need for mach
directories and machine descriptors. To further that goal,
introduce CPU_METHOD_OF_DECLARE() to allow cpu hotplug/smp
support to be separated from the machine descriptors.
Implementers should specify an enable-method property in their
cpus node and then implement a matching set of smp_ops in their
hotplug/smp code, wiring it up with the CPU_METHOD_OF_DECLARE()
macro. When the kernel is compiled we'll collect all the
enable-method smp_ops into one section for use at boot.
At boot time we'll look for an enable-method in each cpu node and
try to match that against all known CPU enable methods in the
kernel. If there are no enable-methods in the cpu nodes we
fallback to the cpus node and try to use any enable-method found
there. If that doesn't work we fall back to the old way of using
the machine descriptor.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: <devicetree@vger.kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
arch/arm/include/asm/smp.h | 9 +++++++++
arch/arm/kernel/devtree.c | 38 ++++++++++++++++++++++++++++++++++++++
include/asm-generic/vmlinux.lds.h | 10 ++++++++++
3 files changed, 57 insertions(+)
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index a8cae71c..c27ec55 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -112,6 +112,15 @@ struct smp_operations {
#endif
};
+struct of_cpu_method {
+ const char *method;
+ struct smp_operations *ops;
+};
+
+#define CPU_METHOD_OF_DECLARE(name, _method, _ops) \
+ static const struct of_cpu_method __cpu_method_of_table_##name \
+ __used __section(__cpu_method_of_table) \
+ = { .method = _method, .ops = _ops }
/*
* set platform specific SMP operations
*/
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f35906b..71a8592 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -25,6 +25,7 @@
#include <asm/smp_plat.h>
#include <asm/mach/arch.h>
#include <asm/mach-types.h>
+#include <asm/smp.h>
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
@@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
}
}
+#ifdef CONFIG_SMP
+extern struct of_cpu_method __cpu_method_of_table[];
+
+static const struct of_cpu_method __cpu_method_of_table_sentinel
+ __used __section(__cpu_method_of_table_end);
+
+static int __init set_smp_ops_by_method(struct device_node *node)
+{
+ const char *method;
+ struct of_cpu_method *m = __cpu_method_of_table;
+
+ if (of_property_read_string(node, "enable-method", &method))
+ return 0;
+
+ for (; m != &__cpu_method_of_table_sentinel; m++)
+ if (!strcmp(m->method, method)) {
+ smp_set_ops(m->ops);
+ return 1;
+ }
+
+ return 0;
+}
+#else
+static inline int set_smp_ops_by_method(struct device_node *node)
+{
+ return 1;
+}
+#endif
+
+
/*
* arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
* and builds the cpu logical map array containing MPIDR values related to
@@ -79,6 +110,7 @@ void __init arm_dt_init_cpu_maps(void)
* read as 0.
*/
struct device_node *cpu, *cpus;
+ int found_method = 0;
u32 i, j, cpuidx = 1;
u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
@@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
}
tmp_map[i] = hwid;
+
+ if (!found_method)
+ found_method = set_smp_ops_by_method(cpu);
}
+ if (!found_method)
+ set_smp_ops_by_method(cpus);
+
if (!bootcpu_valid) {
pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
return;
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 83e2c31..918b1b5 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -167,6 +167,15 @@
#define CLK_OF_TABLES()
#endif
+#ifdef CONFIG_SMP
+#define CPU_METHOD_OF_TABLES() . = ALIGN(8); \
+ VMLINUX_SYMBOL(__cpu_method_of_table) = .; \
+ *(__cpu_method_of_table) \
+ *(__cpu_method_of_table_end)
+#else
+#define CPU_METHOD_OF_TABLES()
+#endif
+
#define KERNEL_DTB() \
STRUCT_ALIGN(); \
VMLINUX_SYMBOL(__dtb_start) = .; \
@@ -490,6 +499,7 @@
MEM_DISCARD(init.rodata) \
CLK_OF_TABLES() \
CLKSRC_OF_TABLES() \
+ CPU_METHOD_OF_TABLES() \
KERNEL_DTB() \
IRQCHIP_OF_MATCH_TABLE()
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related [flat|nested] 25+ messages in thread* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-01 22:08 ` [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp Stephen Boyd
@ 2013-11-05 17:24 ` Kumar Gala
2013-11-05 17:27 ` Stephen Boyd
[not found] ` <1383343739-23080-6-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
1 sibling, 1 reply; 25+ messages in thread
From: Kumar Gala @ 2013-11-05 17:24 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, Mark Rutland, Russell King, devicetree
On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
> The goal of multi-platform kernels is to remove the need for mach
> directories and machine descriptors. To further that goal,
> introduce CPU_METHOD_OF_DECLARE() to allow cpu hotplug/smp
> support to be separated from the machine descriptors.
> Implementers should specify an enable-method property in their
> cpus node and then implement a matching set of smp_ops in their
> hotplug/smp code, wiring it up with the CPU_METHOD_OF_DECLARE()
> macro. When the kernel is compiled we'll collect all the
> enable-method smp_ops into one section for use at boot.
>
> At boot time we'll look for an enable-method in each cpu node and
> try to match that against all known CPU enable methods in the
> kernel. If there are no enable-methods in the cpu nodes we
> fallback to the cpus node and try to use any enable-method found
> there. If that doesn't work we fall back to the old way of using
> the machine descriptor.
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: <devicetree@vger.kernel.org>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> ---
> arch/arm/include/asm/smp.h | 9 +++++++++
> arch/arm/kernel/devtree.c | 38 ++++++++++++++++++++++++++++++++++++++
> include/asm-generic/vmlinux.lds.h | 10 ++++++++++
> 3 files changed, 57 insertions(+)
>
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index a8cae71c..c27ec55 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -112,6 +112,15 @@ struct smp_operations {
> #endif
> };
>
> +struct of_cpu_method {
> + const char *method;
> + struct smp_operations *ops;
> +};
> +
> +#define CPU_METHOD_OF_DECLARE(name, _method, _ops) \
> + static const struct of_cpu_method __cpu_method_of_table_##name \
> + __used __section(__cpu_method_of_table) \
> + = { .method = _method, .ops = _ops }
> /*
> * set platform specific SMP operations
> */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f35906b..71a8592 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -25,6 +25,7 @@
> #include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
> +#include <asm/smp.h>
>
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
> }
> }
>
> +#ifdef CONFIG_SMP
> +extern struct of_cpu_method __cpu_method_of_table[];
> +
> +static const struct of_cpu_method __cpu_method_of_table_sentinel
> + __used __section(__cpu_method_of_table_end);
> +
> +static int __init set_smp_ops_by_method(struct device_node *node)
> +{
> + const char *method;
> + struct of_cpu_method *m = __cpu_method_of_table;
> +
> + if (of_property_read_string(node, "enable-method", &method))
> + return 0;
> +
> + for (; m != &__cpu_method_of_table_sentinel; m++)
> + if (!strcmp(m->method, method)) {
> + smp_set_ops(m->ops);
> + return 1;
> + }
> +
> + return 0;
> +}
> +#else
> +static inline int set_smp_ops_by_method(struct device_node *node)
> +{
> + return 1;
> +}
> +#endif
> +
> +
> /*
> * arm_dt_init_cpu_maps - Function retrieves cpu nodes from the device tree
> * and builds the cpu logical map array containing MPIDR values related to
> @@ -79,6 +110,7 @@ void __init arm_dt_init_cpu_maps(void)
> * read as 0.
> */
> struct device_node *cpu, *cpus;
> + int found_method = 0;
> u32 i, j, cpuidx = 1;
> u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
>
> @@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
> }
>
> tmp_map[i] = hwid;
> +
> + if (!found_method)
> + found_method = set_smp_ops_by_method(cpu);
> }
>
> + if (!found_method)
> + set_smp_ops_by_method(cpus);
> +
I assume this if for the case that the enable method is in the cpus{ } container but not in a specific cpu node?
If so, the binding is not clear that we allow this. Also a comment would probably be nice.
> if (!bootcpu_valid) {
> pr_warn("DT missing boot CPU MPIDR[23:0], fall back to default cpu_logical_map\n");
> return;
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-05 17:24 ` Kumar Gala
@ 2013-11-05 17:27 ` Stephen Boyd
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Boyd @ 2013-11-05 17:27 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-arm-kernel, David Brown, Rohit Vaswani, linux-kernel,
linux-arm-msm, Mark Rutland, Russell King, devicetree
On 11/05/13 09:24, Kumar Gala wrote:
> On Nov 1, 2013, at 5:08 PM, Stephen Boyd wrote:
>
>> @@ -150,8 +182,14 @@ void __init arm_dt_init_cpu_maps(void)
>> }
>>
>> tmp_map[i] = hwid;
>> +
>> + if (!found_method)
>> + found_method = set_smp_ops_by_method(cpu);
>> }
>>
>> + if (!found_method)
>> + set_smp_ops_by_method(cpus);
>> +
> I assume this if for the case that the enable method is in the cpus{ } container but not in a specific cpu node?
>
> If so, the binding is not clear that we allow this. Also a comment would probably be nice.
Sure I'll add a comment to that effect and clarify the binding.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread
[parent not found: <1383343739-23080-6-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
[not found] ` <1383343739-23080-6-git-send-email-sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
@ 2013-11-07 1:50 ` Josh Cartwright
2013-11-07 22:34 ` Stephen Boyd
0 siblings, 1 reply; 25+ messages in thread
From: Josh Cartwright @ 2013-11-07 1:50 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Rohit Vaswani,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, David Brown
Hey Stephen-
Nit/suggestion below:
On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
[..]
> diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
> index a8cae71c..c27ec55 100644
> --- a/arch/arm/include/asm/smp.h
> +++ b/arch/arm/include/asm/smp.h
> @@ -112,6 +112,15 @@ struct smp_operations {
> #endif
> };
>
> +struct of_cpu_method {
> + const char *method;
> + struct smp_operations *ops;
> +};
> +
> +#define CPU_METHOD_OF_DECLARE(name, _method, _ops) \
> + static const struct of_cpu_method __cpu_method_of_table_##name \
> + __used __section(__cpu_method_of_table) \
> + = { .method = _method, .ops = _ops }
> /*
> * set platform specific SMP operations
> */
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index f35906b..71a8592 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -25,6 +25,7 @@
> #include <asm/smp_plat.h>
> #include <asm/mach/arch.h>
> #include <asm/mach-types.h>
> +#include <asm/smp.h>
>
> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> {
> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
> }
> }
>
> +#ifdef CONFIG_SMP
> +extern struct of_cpu_method __cpu_method_of_table[];
> +
> +static const struct of_cpu_method __cpu_method_of_table_sentinel
> + __used __section(__cpu_method_of_table_end);
Having a sentinel allocated into the linked image makes a lot of sense
in other cases (IRQCHIP/CLOCKSOURCE_OF_DECLARE, etc), where it's used to
terminate an of_device_id table (as is expected by of_match_table and
friends).
In this case, however, you aren't building a match table, so having a
sentinel allocated isn't necessary. I'd suggest bookending the table
with a VMLINUX_SYMBOL(__cpu_method_of_table_end) instead.
A whole 2 pointers worth of savings!
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread* Re: [PATCH 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
2013-11-07 1:50 ` Josh Cartwright
@ 2013-11-07 22:34 ` Stephen Boyd
0 siblings, 0 replies; 25+ messages in thread
From: Stephen Boyd @ 2013-11-07 22:34 UTC (permalink / raw)
To: Josh Cartwright
Cc: linux-arm-kernel, Mark Rutland, devicetree, Russell King,
linux-arm-msm, Rohit Vaswani, linux-kernel, David Brown
On 11/06/13 17:50, Josh Cartwright wrote:
> On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
>> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
>> index f35906b..71a8592 100644
>> --- a/arch/arm/kernel/devtree.c
>> +++ b/arch/arm/kernel/devtree.c
>> @@ -25,6 +25,7 @@
>> #include <asm/smp_plat.h>
>> #include <asm/mach/arch.h>
>> #include <asm/mach-types.h>
>> +#include <asm/smp.h>
>>
>> void __init early_init_dt_add_memory_arch(u64 base, u64 size)
>> {
>> @@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
>> }
>> }
>>
>> +#ifdef CONFIG_SMP
>> +extern struct of_cpu_method __cpu_method_of_table[];
>> +
>> +static const struct of_cpu_method __cpu_method_of_table_sentinel
>> + __used __section(__cpu_method_of_table_end);
> Having a sentinel allocated into the linked image makes a lot of sense
> in other cases (IRQCHIP/CLOCKSOURCE_OF_DECLARE, etc), where it's used to
> terminate an of_device_id table (as is expected by of_match_table and
> friends).
>
> In this case, however, you aren't building a match table, so having a
> sentinel allocated isn't necessary. I'd suggest bookending the table
> with a VMLINUX_SYMBOL(__cpu_method_of_table_end) instead.
>
> A whole 2 pointers worth of savings!
>
Yes, will do. Thanks.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply [flat|nested] 25+ messages in thread