From patchwork Fri Apr 6 09:37:03 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sekhar Nori X-Patchwork-Id: 10325811 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D03CB6053F for ; Fri, 6 Apr 2018 09:38:30 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BF6A029272 for ; Fri, 6 Apr 2018 09:38:30 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B3E00292D0; Fri, 6 Apr 2018 09:38:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3D7B729272 for ; Fri, 6 Apr 2018 09:38:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751494AbeDFJiR (ORCPT ); Fri, 6 Apr 2018 05:38:17 -0400 Received: from lelnx194.ext.ti.com ([198.47.27.80]:19116 "EHLO lelnx194.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751367AbeDFJiQ (ORCPT ); Fri, 6 Apr 2018 05:38:16 -0400 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by lelnx194.ext.ti.com (8.15.1/8.15.1) with ESMTP id w369bArI002482; Fri, 6 Apr 2018 04:37:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ti.com; s=ti-com-17Q1; t=1523007430; bh=Q40KWJNZ8FbtcHGKastsFZMTg5Tb40Fj6RtXMH1Z/60=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=RukGKhw6w77LueUnC4vPUHCPBvUMp1gJu0dkTAYDnrpAluYYARBTUovKnw7OJeCRP Zd8wzSI6Fz19FMpQWE1IRtrIDvjODB3QFVscGyVGCrVyYMfs8HZqivsn5mXdJ8N8X8 LwWqj1nov83l5sZXEiC/SFr6+rEM6z0zbNOibZE4= Received: from DLEE102.ent.ti.com (dlee102.ent.ti.com [157.170.170.32]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id w369bAeO018789; Fri, 6 Apr 2018 04:37:10 -0500 Received: from DLEE102.ent.ti.com (157.170.170.32) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1261.35; Fri, 6 Apr 2018 04:37:10 -0500 Received: from dlep32.itg.ti.com (157.170.170.100) by DLEE102.ent.ti.com (157.170.170.32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.1.1261.35 via Frontend Transport; Fri, 6 Apr 2018 04:37:09 -0500 Received: from [172.24.190.172] (ileax41-snat.itg.ti.com [10.172.224.153]) by dlep32.itg.ti.com (8.14.3/8.13.8) with ESMTP id w369b3Xn027294; Fri, 6 Apr 2018 04:37:04 -0500 Subject: Re: [PATCH v5 12/44] clk: davinci: Add platform information for TI DA850 PSC To: Bartosz Golaszewski CC: Michael Turquette , David Lechner , linux-clk , devicetree , Linux ARM , Stephen Boyd , Rob Herring , Mark Rutland , Kevin Hilman , Adam Ford , Linux Kernel Mailing List References: <1515377863-20358-1-git-send-email-david@lechnology.com> <1515377863-20358-13-git-send-email-david@lechnology.com> <69bc0848-0698-b936-96a3-2257a5e27809@ti.com> From: Sekhar Nori Message-ID: <57f2182e-09b4-2cab-5602-9d0e029495be@ti.com> Date: Fri, 6 Apr 2018 15:07:03 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Bart, On Thursday 05 April 2018 09:21 PM, Bartosz Golaszewski wrote: > 2018-04-05 16:36 GMT+02:00 Sekhar Nori : >> On Thursday 05 April 2018 07:14 PM, Bartosz Golaszewski wrote: >>> 2018-04-05 15:09 GMT+02:00 Sekhar Nori : >>>> Hi Bartosz, >>>> >>>> On Friday 09 February 2018 10:18 PM, Michael Turquette wrote: >>>>> On Fri, Feb 9, 2018 at 8:22 AM, Bartosz Golaszewski wrote: >>>>>> 2018-01-08 3:17 GMT+01:00 David Lechner : >>>> >>>>>> 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 > > Yes, you can still find it on my github[1]. > > Bart > > [1] github.com:brgl/linux.git topic/davinci-genpd-final-v2 The panic issue in your branch is not related to genpd. Its because you are accessing platform bus before it is initialized. The attached[1] patch on top of your branch made it boot again. With your branch booting, I can see genpd related debugfs entries getting created. I don't see devices being attached to the domains you have though. I did not debug that. I suspect some matching issue. Can you please check that and confirm there is no issue with genpd and using CLK_OF_DECLARE() to initialize clocks? Unless you report an issue back, or Mike and Stephen have ideas about how to handle the dependency between PSC/PLL derived timer clock initialization and and timer_probe(), I think we need to move back to using CLK_OF_DECLARE(). Thanks, Sekhar ---8<--- the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/clk/davinci/psc.c b/drivers/clk/davinci/psc.c index 9d9f94eee544..7e3d114efdac 100644 --- a/drivers/clk/davinci/psc.c +++ b/drivers/clk/davinci/psc.c @@ -281,12 +281,18 @@ int __davinci_psc_register_clocks(const struct davinci_psc_clk_info *info, } } - DO_ONCE(pm_clk_add_notifier, - &platform_bus_type, &platform_bus_notifier); - return 0; } +static int __init davinci_pm_runtime_init(void) +{ + pm_clk_add_notifier(&platform_bus_type, &platform_bus_notifier); + + return 0; +} +core_initcall(davinci_pm_runtime_init); + int davinci_psc_register_clocks(const struct davinci_psc_clk_info *info, void __iomem *base) { -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in