| Message ID | 1542589274-13878-3-git-send-email-sugaya.taichi@socionext.com |
|---|---|
| State | New |
| Headers | show |
| Series | None | expand |
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 >
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 >
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.
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 -- 1.9.1