Hi Heiko, On 16 April 2014 22:55, Heiko Stübner <heiko@xxxxxxxxx> wrote: > Hi, > > Am Mittwoch, 16. April 2014, 16:35:36 schrieb Arnd Bergmann: >> On Wednesday 16 April 2014 17:20:51 Sachin Kamat wrote: >> > Instead of hardcoding the SYSRAM details for each SoC, >> > pass this information through device tree (DT) and make >> > the code SoC agnostic. >> > >> > Signed-off-by: Sachin Kamat <sachin.kamat@xxxxxxxxxx> >> > --- >> > Rebased on latest linux-next. >> >> Thanks for sending this again. I'd like Heiko to have a look >> and provide an Ack if he's happy with it. >> >> It seems similar to what he did with the SRAM for mach-rockchip, >> and if it is we should use the same binding that he introduced, >> which would be a minor variation of this. > > The sram binding is derived from the generic reserved-memory bindings to > enable the sram in general to be used generically through the sram driver, > while still retaining some areas for special purposes, like the smp-trampoline > in my case. > > From my reading of platsmp.c, it looks like offset+0x4 starts the so called > boot-registesr, which get the smp-start-address written to. > > So I guess it all depends on what is contained in the rest of the sysram. If > it is all covered with such special registers or other special uses, the code > below is fine. But if the most of the area is just general purpose sram, a > solution like on rockchip might be nicer - i.e. handling the sysram via the > sram driver and declaring a reserved section for the boot registers. Thanks for your inputs. In our case, we use sram for secondary boot addresses but could not find any other general purpose use. > So, depending on the above: > Acked-by: Heiko Stuebner <heiko@xxxxxxxxx> So I believe your ack applies to our case :). Thanks again. -- With warm regards, Sachin -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
