Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Tue, Jan 29, 2019 at 05:28:48PM +0900, Sugaya, Taichi wrote:
> 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
> > > > wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > > > > > 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 000..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 0x ) 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
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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
wrote:
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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.
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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
> > wrote:
> > >
> > > Hi
> > >
> > > On 2018/12/04 0:49, Rob Herring wrote:
> > > > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > > > 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 000..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 0x ) 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.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi
On 2018/12/04 22:32, Rob Herring wrote:
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
On 2018/12/04 22:32, Rob Herring wrote:
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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.
Thanks.
OK, try to use the spin-table.
Best Regards,
Sugaya Taichi
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
On 2018/12/04 22:32, Rob Herring wrote:
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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.
Thanks.
OK, try to use the spin-table.
Best Regards,
Sugaya Taichi
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
>
> Hi
>
> On 2018/12/04 0:49, Rob Herring wrote:
> > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > 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 000..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 0x ) 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.
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Tue, Dec 4, 2018 at 5:30 AM Sugaya, Taichi
wrote:
>
> Hi
>
> On 2018/12/04 0:49, Rob Herring wrote:
> > On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
> > 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 000..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 0x ) 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.
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi
On 2018/12/04 0:49, Rob Herring wrote:
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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).
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
On Mon, Dec 3, 2018 at 1:42 AM Sugaya, Taichi
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 000..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 0x ) 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).
Rob
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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 000..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 0x ) 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?
Thanks
Sugaya Taichi
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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 000..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 0x ) 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?
Thanks
Sugaya Taichi
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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 000..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.
>
> 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?
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
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 000..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.
>
> 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?
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
Thank you for your comments.
On 2018/11/28 11:01, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:07)
Add DT bindings document for Milbeaut trampoline.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
1 file changed, 12 insertions(+)
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 000..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.)
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?
Thanks
Sugaya Taichi
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Hi,
Thank you for your comments.
On 2018/11/28 11:01, Stephen Boyd wrote:
Quoting Sugaya Taichi (2018-11-18 17:01:07)
Add DT bindings document for Milbeaut trampoline.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
1 file changed, 12 insertions(+)
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 000..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.)
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?
Thanks
Sugaya Taichi
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Quoting Sugaya Taichi (2018-11-18 17:01:07)
> Add DT bindings document for Milbeaut trampoline.
>
> Signed-off-by: Sugaya Taichi
> ---
> .../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
>
> 1 file changed, 12 insertions(+)
> 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 000..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.
> + 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.
Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Quoting Sugaya Taichi (2018-11-18 17:01:07)
> Add DT bindings document for Milbeaut trampoline.
>
> Signed-off-by: Sugaya Taichi
> ---
> .../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
>
> 1 file changed, 12 insertions(+)
> 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 000..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.
> + 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.
[PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Add DT bindings document for Milbeaut trampoline.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
1 file changed, 12 insertions(+)
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 000..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>;
+ };
--
1.9.1
[PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
Add DT bindings document for Milbeaut trampoline.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/soc/socionext/socionext,m10v.txt | 12
1 file changed, 12 insertions(+)
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 000..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>;
+ };
--
1.9.1
