Re: [PATCH 02/14] dt-bindings: soc: milbeaut: Add Milbeaut trampoline description
From: "Sugaya, Taichi" <sugaya.taichi@socionext.com>
Date: 2018-12-03 07:43:00
Also in:
linux-clk, linux-devicetree, linux-serial, lkml
Hi, On 2018/11/30 17:16, Stephen Boyd wrote:
Quoting Sugaya, Taichi (2018-11-29 04:24:51)quoted
On 2018/11/28 11:01, Stephen Boyd wrote:quoted
Quoting Sugaya Taichi (2018-11-18 17:01:07)quoted
create mode 100644 Documentation/devicetree/bindings/soc/socionext/socionext,m10v.txtdiff --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.quoted
quoted
+ 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.
quoted
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
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel