On Thursday 05 April 2018 07:14 PM, Bartosz Golaszewski wrote: > 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. Do you have the code where you faced the problem stashed somewhere? I am not (yet) advocating going back to CLK_OF_DECLARE(). But there is a definite issue with timer being ready when not using CLK_OF_DECLARE(). So, I want to make sure there the reason why we are going down the platform device path is a amply clear. Thanks, Sekhar -- 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
