On Thursday 16 January 2014, Marc C wrote: > > And then you can add a regular device driver to drivers/reset that provides a > > device_reset() API to other drivers, or a system-reset function to be registered as > > arm_pm_restart. This driver would use syscon_regmap_lookup_by_phandle() to get access > > to a regmap pointer, and then use either hardcoded offsets into the regmap, or get > > those offsets from numbers in the devicetree, as provided in the example above. > > I was able to port a standalone "reboot" driver using syscon + regmap. However, for the > SMP initialization case, it turns out that syscon is configured after SMP init. Do you > have any advice for this type of situation? > > I'd hate to go around in circles, but without resorting to hard-coded offsets, perhaps I > can just add the remaining "non-regmap" register offsets in the DT? You are not the first one to stumble over this problem. There are two ways to get out of it, and we should probably implement both in the long run: 1. Other platforms also require the syscon driver to be active before the regular device driver probing starts. Michal Simek has the same issue in the zynq clock driver that you have for SMP initialization. We have talked about this with Mark Brown already, and I think we will find a solution for this in the end, but it's not as straightforward as I first hoped. We can probably use help in this area. 2. There is actually no reason for the SMP code to be called this early, and multiple platforms would like to move SMP init to a later stage. Stephen Boyd has recently started reworking the way we do SMP init, and he may have some more insight. In the meantime, I'd suggest you do the binding under the assumption that it will work eventually, and then work around the current limitations in the SMP code by looking for the device nodes you need and map them manually, as you did in the previous versions of your patch set. Arnd -- 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
