| Message ID | 1542589274-13878-3-git-send-email-sugaya.taichi@socionext.com |
|---|---|
| State | Changes Requested, archived |
| Headers | show |
| Series | Add basic support for Socionext Milbeaut M10V SoCs | expand |
| Context | Check | Description |
|---|---|---|
| robh/checkpatch | success |
Quoting Sugaya Taichi (2018-11-18 17:01:07) > 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 > > 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. > + 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.
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<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 >> >> 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.) 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
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. > > 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?
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? Thanks Sugaya Taichi >
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). Rob
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 >
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. Rob
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. Thanks. OK, try to use the spin-table. Best Regards, Sugaya Taichi > > Rob >
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 >
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.
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.
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 > > > > <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. Please do - the "spin" approach was a hack to allow ARM Ltd's platforms to work. These platforms have no power control or reset of secondary CPUs and no low power states (so can't suspend/resume). Early firmware only had the capabilities to release _all_ secondary CPUs to the kernel together. The "spin" approach is incompatible with suspend/resume, hibernate, and kexec features of the kernel. Real platforms do not have these problems, and thus should not use the spin-table approach. Modern platforms use PSCI to make the control of low power modes and secondary CPUs independent of the kernel.
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>; + };
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