[02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description

Message ID 1542589274-13878-3-git-send-email-sugaya.taichi@socionext.com
State New
Headers show
Series
  • Untitled series #16475
Related show

Commit Message

Sugaya, Taichi Nov. 19, 2018, 1:01 a.m.
Add DT bindings document for Milbeaut trampoline.

Signed-off-by: Sugaya Taichi <sugaya.taichi@socionext.com>

---
 .../devicetree/bindings/soc/socionext/socionext,m10v.txt     | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

-- 
1.9.1

Comments

Sugaya, Taichi Dec. 4, 2018, 11:30 a.m. | #1
Hi

On 2018/12/04 0:49, Rob Herring wrote:
> On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi

> <sugaya.taichi@socionext.com> wrote:

>>

>> Hi,

>>

>> On 2018/11/30 17:16, Stephen Boyd wrote:

>>> Quoting Sugaya, Taichi (2018-11-29 04:24:51)

>>>> On 2018/11/28 11:01, Stephen Boyd wrote:

>>>>> Quoting Sugaya Taichi (2018-11-18 17:01:07)

>>>>>>     create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>

>>>>>> diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>> new file mode 100644

>>>>>> index 0000000..f5d906c

>>>>>> --- /dev/null

>>>>>> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>> @@ -0,0 +1,12 @@

>>>>>> +Socionext M10V SMP trampoline driver binding

>>>>>> +

>>>>>> +This is a driver to wait for sub-cores while boot process.

>>>>>> +

>>>>>> +- compatible: should be "socionext,smp-trampoline"

>>>>>> +- reg: should be <0x4C000100 0x100>

>>>>>> +

>>>>>> +EXAMPLE

>>>>>> +       trampoline: trampoline@0x4C000100 {

>>>>> Drop the 0x part of unit addresses.

>>>>

>>>> Okay.

>>>>

>>>>

>>>>>> +               compatible = "socionext,smp-trampoline";

>>>>>> +               reg = <0x4C000100 0x100>;

>>>>> Looks like a software construct, which we wouldn't want to put into DT

>>>>> this way. DT doesn't describe drivers.

>>>> We would like to use this node only getting the address of the

>>>> trampoline area

>>>> in which sub-cores wait.  (They have finished to go to this area in previous

>>>> bootloader process.)

>>>

>>> Is this area part of memory, or a special SRAM? If it's part of memory,

>>> I would expect this node to be under the reserved-memory node and

>>> pointed to by some other node that uses this region. Could even be the

>>> CPU nodes.

>>

>> Yes, 0x4C000100 is a part of memory under the reserved-memory node. So

>> we would like to use the SRAM ( allocated 0x00000000 ) area instead.

>> BTW, sorry, the trampoline address of this example is simply wrong.  We

>> were going to use a part of the SRAM from the beginning.

>>

>>>

>>>>

>>>> So should we embed the constant value in source codes instead of getting

>>>> from

>>>> DT because the address is constant at the moment? Or is there other

>>>> approach?

>>>>

>>>

>>> If it's constant then that also works. Why does it need to come from DT

>>> at all then?

>>

>> We think it is not good to embed constant value in driver codes and do

>> not have another way...

>> Are there better ways?

> 

> If this is just memory, can you use the standard spin-table binding in

> the DT spec? There are some requirements like 64-bit values even on

> 32-bit machines (though this gets violated).


The spin-table seems to be used on only 64-bit arch. Have it ever worked 
on 32-bit machine?
And I would like not to use it because avoid violation.

Thanks
Sugaya Taichi


> 

> Rob

>
Sugaya, Taichi Jan. 22, 2019, 11:36 a.m. | #2
Hi

On 2018/12/04 22:32, Rob Herring wrote:
> On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi

> <sugaya.taichi@socionext.com> wrote:

>>

>> Hi

>>

>> On 2018/12/04 0:49, Rob Herring wrote:

>>> On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi

>>> <sugaya.taichi@socionext.com> wrote:

>>>>

>>>> Hi,

>>>>

>>>> On 2018/11/30 17:16, Stephen Boyd wrote:

>>>>> Quoting Sugaya, Taichi (2018-11-29 04:24:51)

>>>>>> On 2018/11/28 11:01, Stephen Boyd wrote:

>>>>>>> Quoting Sugaya Taichi (2018-11-18 17:01:07)

>>>>>>>>      create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>>

>>>>>>>> diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>> new file mode 100644

>>>>>>>> index 0000000..f5d906c

>>>>>>>> --- /dev/null

>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>> @@ -0,0 +1,12 @@

>>>>>>>> +Socionext M10V SMP trampoline driver binding

>>>>>>>> +

>>>>>>>> +This is a driver to wait for sub-cores while boot process.

>>>>>>>> +

>>>>>>>> +- compatible: should be "socionext,smp-trampoline"

>>>>>>>> +- reg: should be <0x4C000100 0x100>

>>>>>>>> +

>>>>>>>> +EXAMPLE

>>>>>>>> +       trampoline: trampoline@0x4C000100 {

>>>>>>> Drop the 0x part of unit addresses.

>>>>>>

>>>>>> Okay.

>>>>>>

>>>>>>

>>>>>>>> +               compatible = "socionext,smp-trampoline";

>>>>>>>> +               reg = <0x4C000100 0x100>;

>>>>>>> Looks like a software construct, which we wouldn't want to put into DT

>>>>>>> this way. DT doesn't describe drivers.

>>>>>> We would like to use this node only getting the address of the

>>>>>> trampoline area

>>>>>> in which sub-cores wait.  (They have finished to go to this area in previous

>>>>>> bootloader process.)

>>>>>

>>>>> Is this area part of memory, or a special SRAM? If it's part of memory,

>>>>> I would expect this node to be under the reserved-memory node and

>>>>> pointed to by some other node that uses this region. Could even be the

>>>>> CPU nodes.

>>>>

>>>> Yes, 0x4C000100 is a part of memory under the reserved-memory node. So

>>>> we would like to use the SRAM ( allocated 0x00000000 ) area instead.

>>>> BTW, sorry, the trampoline address of this example is simply wrong.  We

>>>> were going to use a part of the SRAM from the beginning.

>>>>

>>>>>

>>>>>>

>>>>>> So should we embed the constant value in source codes instead of getting

>>>>>> from

>>>>>> DT because the address is constant at the moment? Or is there other

>>>>>> approach?

>>>>>>

>>>>>

>>>>> If it's constant then that also works. Why does it need to come from DT

>>>>> at all then?

>>>>

>>>> We think it is not good to embed constant value in driver codes and do

>>>> not have another way...

>>>> Are there better ways?

>>>

>>> If this is just memory, can you use the standard spin-table binding in

>>> the DT spec? There are some requirements like 64-bit values even on

>>> 32-bit machines (though this gets violated).

>>

>> The spin-table seems to be used on only 64-bit arch. Have it ever worked

>> on 32-bit machine?

> 

> Yes.

> 

>> And I would like not to use it because avoid violation.

> 

> The issue now that I remember is cpu-release-addr is defined to always

> be a 64-bit value while some platforms made it a 32-bit value.

> 'cpu-release-addr' is also used for some other enable-methods.


I have a question about the spin-table.
The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so 
can not be compiled in arm-v7 arch. That means the spin-table can not be 
used arm-v7 arch..? , or is there the way to compile the code in arm-v7 
arch?

Thanks,
Sugaya Taichi

> 

> Rob

>
Sugaya, Taichi Jan. 29, 2019, 8:28 a.m. | #3
Hi,

On 2019/01/22 20:50, Russell King - ARM Linux admin wrote:
> On Tue, Jan 22, 2019 at 08:36:03PM +0900, Sugaya, Taichi wrote:

>> Hi

>>

>> On 2018/12/04 22:32, Rob Herring wrote:

>>> On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi

>>> <sugaya.taichi@socionext.com> wrote:

>>>>

>>>> Hi

>>>>

>>>> On 2018/12/04 0:49, Rob Herring wrote:

>>>>> On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi

>>>>> <sugaya.taichi@socionext.com> wrote:

>>>>>>

>>>>>> Hi,

>>>>>>

>>>>>> On 2018/11/30 17:16, Stephen Boyd wrote:

>>>>>>> Quoting Sugaya, Taichi (2018-11-29 04:24:51)

>>>>>>>> On 2018/11/28 11:01, Stephen Boyd wrote:

>>>>>>>>> Quoting Sugaya Taichi (2018-11-18 17:01:07)

>>>>>>>>>>       create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>>>>

>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>>>> new file mode 100644

>>>>>>>>>> index 0000000..f5d906c

>>>>>>>>>> --- /dev/null

>>>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt

>>>>>>>>>> @@ -0,0 +1,12 @@

>>>>>>>>>> +Socionext M10V SMP trampoline driver binding

>>>>>>>>>> +

>>>>>>>>>> +This is a driver to wait for sub-cores while boot process.

>>>>>>>>>> +

>>>>>>>>>> +- compatible: should be "socionext,smp-trampoline"

>>>>>>>>>> +- reg: should be <0x4C000100 0x100>

>>>>>>>>>> +

>>>>>>>>>> +EXAMPLE

>>>>>>>>>> +       trampoline: trampoline@0x4C000100 {

>>>>>>>>> Drop the 0x part of unit addresses.

>>>>>>>>

>>>>>>>> Okay.

>>>>>>>>

>>>>>>>>

>>>>>>>>>> +               compatible = "socionext,smp-trampoline";

>>>>>>>>>> +               reg = <0x4C000100 0x100>;

>>>>>>>>> Looks like a software construct, which we wouldn't want to put into DT

>>>>>>>>> this way. DT doesn't describe drivers.

>>>>>>>> We would like to use this node only getting the address of the

>>>>>>>> trampoline area

>>>>>>>> in which sub-cores wait.  (They have finished to go to this area in previous

>>>>>>>> bootloader process.)

>>>>>>>

>>>>>>> Is this area part of memory, or a special SRAM? If it's part of memory,

>>>>>>> I would expect this node to be under the reserved-memory node and

>>>>>>> pointed to by some other node that uses this region. Could even be the

>>>>>>> CPU nodes.

>>>>>>

>>>>>> Yes, 0x4C000100 is a part of memory under the reserved-memory node. So

>>>>>> we would like to use the SRAM ( allocated 0x00000000 ) area instead.

>>>>>> BTW, sorry, the trampoline address of this example is simply wrong.  We

>>>>>> were going to use a part of the SRAM from the beginning.

>>>>>>

>>>>>>>

>>>>>>>>

>>>>>>>> So should we embed the constant value in source codes instead of getting

>>>>>>>> from

>>>>>>>> DT because the address is constant at the moment? Or is there other

>>>>>>>> approach?

>>>>>>>>

>>>>>>>

>>>>>>> If it's constant then that also works. Why does it need to come from DT

>>>>>>> at all then?

>>>>>>

>>>>>> We think it is not good to embed constant value in driver codes and do

>>>>>> not have another way...

>>>>>> Are there better ways?

>>>>>

>>>>> If this is just memory, can you use the standard spin-table binding in

>>>>> the DT spec? There are some requirements like 64-bit values even on

>>>>> 32-bit machines (though this gets violated).

>>>>

>>>> The spin-table seems to be used on only 64-bit arch. Have it ever worked

>>>> on 32-bit machine?

>>>

>>> Yes.

>>>

>>>> And I would like not to use it because avoid violation.

>>>

>>> The issue now that I remember is cpu-release-addr is defined to always

>>> be a 64-bit value while some platforms made it a 32-bit value.

>>> 'cpu-release-addr' is also used for some other enable-methods.

>>

>> I have a question about the spin-table.

>> The code "smp_spin_table.c" is only in "arch/arm64/kernel" directory so can

>> not be compiled in arm-v7 arch. That means the spin-table can not be used

>> arm-v7 arch..? , or is there the way to compile the code in arm-v7 arch?

> 

> Why do you think you need it?  Do you have no way to control individual

> CPUs?

> 

> We are going through a process in 32-bit eliminating the "spin table"

> stuff from platforms.

> 


Not always necessary to us and considering the history I think it is not 
suitable to use the spin-table.
I try to use another way.

Patch

diff --git a/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
new file mode 100644
index 0000000..f5d906c
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txt
@@ -0,0 +1,12 @@ 
+Socionext M10V SMP trampoline driver binding
+
+This is a driver to wait for sub-cores while boot process.
+
+- compatible: should be "socionext,smp-trampoline"
+- reg: should be <0x4C000100 0x100>
+
+EXAMPLE
+	trampoline: trampoline@0x4C000100 {
+		compatible = "socionext,smp-trampoline";
+		reg = <0x4C000100 0x100>;
+	};