2018-04-05 15:09 GMT+02:00 Sekhar Nori <nsekhar@xxxxxx>: > Hi Bartosz, > > On Friday 09 February 2018 10:18 PM, Michael Turquette wrote: >> On Fri, Feb 9, 2018 at 8:22 AM, Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >>> 2018-01-08 3:17 GMT+01:00 David Lechner <david@xxxxxxxxxxxxxx>: > >>> Hi David, >>> >>> I've been working on moving the genpd code from its own driver to the >>> psc one. I couldn't get the system to boot though and problems >>> happened very early in the boot sequence. I struggled to figure out >>> what's happening, but eventually I noticed that psc uses >>> CLK_OF_DECLARE() to initialize clocks. The functions registered this >>> way are called very early in the boot sequence, way before >>> late_initcall() in which the genpd framework is initialized. This of > > late_initcall() is too late for genpd to be initialized. As you may have > seen with the latest set of patches, we have problems with timer > initialization. After converting to platform devices, PSC and PLL clocks > get initialized post time_init(). We are working that around using > fixed-clocks, which hopefully will work (I still need to test many of > the affected platforms). > > Can you please reply with the exact issue you faced with genpd framework > initialization so we do have that on record. > The exact issue manifested itself in a NULL-pointer dereference panic when I tried moving the genpd code I had initially implemented as a separate platform driver to what I believe was v6 or v7 of David's series (before the psc driver became a platform driver, when it was still using CLK_OF_DECLARE()). When I had tested a simple conversion of that version to a platform_driver, genpd worked fine. I don't have the stack traces from these panics, but I recall some debugfs functions being involved and the genpd late_initcalls are related to debugfs. Looking at it now I don't see how exactly it could fail though. Best regards, Bartosz -- 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
