From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34499C169C4 for ; Fri, 8 Feb 2019 10:22:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E8ECC2086C for ; Fri, 8 Feb 2019 10:22:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549621336; bh=qJ4PHY/7CVgOXoZdtmCv/SmIjH/qESkjY41m9N8CIS8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=dhOfOFo2hgtoI5V9FU4HURTM66AnoVBO0SeQd6SXt3T9RZ3IqjvLyrpQbz/PlCn+j uk1X22g5RGK2jFdGBfSm2ugJiThedXDDdai4ZmwsOHXeIGT6v6u0dIP3eD4T6S9B4n DBTl58efObbVBk5GZbk87rRm9Yjr26LMw7nznj9k= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727086AbfBHKWO (ORCPT ); Fri, 8 Feb 2019 05:22:14 -0500 Received: from mail-ot1-f67.google.com ([209.85.210.67]:33918 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726524AbfBHKWO (ORCPT ); Fri, 8 Feb 2019 05:22:14 -0500 Received: by mail-ot1-f67.google.com with SMTP id t5so5056955otk.1; Fri, 08 Feb 2019 02:22:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mguDmn6uck6DJfJs5vmLhsyZ/GNIgSL9ISKG2EY/jLo=; b=gDpJ1QusNMMzY7BwETlhd4dl4DVRySVr1j8DR6tI5EV6VXBdctP5TMYW6dYcIThrtr DrmgCMkqOFjaBqRaXGP4N0eVjfJP1/Vd3w5q1p5SoEqe6z+ScqlZxCQ2ghKatIRFN70F G2VENgiXC40BcoC2cimLvx9qoem+5jECg8f5VwxnyjaUI1Z24tVxuhpJI3oMztqynK+D Y8YlmKq8qOsWlwZwQ/162RMhHBuzHyPbkX7XjHKdGAtXVjRPZLZLAMy0Fm/si+qvQhNh Hq90LxL84vmORaNH3DecA6Bq/9ODfnDfuOfvu/6TE9yxZv8kNDsXWBRmHduzqb4Sehf4 tgEA== X-Gm-Message-State: AHQUAuYce23Ctc353wlEtWRZ/SKrpAcbE9Hy07mciH8aJI3dn+/AHsJ+ 10cfFK8gCmOSfXu8ZozjSSA9Aje+bMJ8qP8d3gs= X-Google-Smtp-Source: AHgI3IYsArn6kVeqh4Lwhp+PVxrhTNZ+82NCdvB5A8WbYYHRYDC5CdjGQkg6ivUUQYWZWPIAJJTjVxbVPNHjEyHXo58= X-Received: by 2002:a9d:4c84:: with SMTP id m4mr11412179otf.124.1549621332965; Fri, 08 Feb 2019 02:22:12 -0800 (PST) MIME-Version: 1.0 References: <20190207122227.19873-1-m.szyprowski@samsung.com> <20190208064957.zhyue42kpgaoslwm@vireshk-i7> In-Reply-To: <20190208064957.zhyue42kpgaoslwm@vireshk-i7> From: "Rafael J. Wysocki" Date: Fri, 8 Feb 2019 11:22:02 +0100 Message-ID: Subject: Re: [PATCH 0/2] cpufreq/opp: rework regulator initialization To: Viresh Kumar Cc: Marek Szyprowski , Linux Kernel Mailing List , Linux PM , Linux Samsung SoC , "Rafael J . Wysocki" , Nishanth Menon , Stephen Boyd , Bartlomiej Zolnierkiewicz , Dave Gerlach , Wolfram Sang Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 8, 2019 at 7:50 AM Viresh Kumar wrote: > > On 07-02-19, 13:22, Marek Szyprowski wrote: > > Dear All, > > > > Recent commit 9ac6cb5fbb17 ("i2c: add suspended flag and accessors for > > i2c adapters") added a visible warning for an attempt to do i2c transfer > > over a suspended i2c bus. This revealed a long standing issue in the > > cpufreq-dt driver, which gives a following warning during system > > suspend/resume cycle: > > > > --->8--- > > Enabling non-boot CPUs ... > > CPU1 is up > > CPU2 is up > > CPU3 is up > > ------------[ cut here ]------------ > > WARNING: CPU: 4 PID: 29 at drivers/i2c/i2c-core-base.c:1869 __i2c_transfer+0x6f8/0xa50 > > Modules linked in: > > CPU: 4 PID: 29 Comm: cpuhp/4 Tainted: G W 5.0.0-rc4-next-20190131-00024-g54b06b29cc65 #5324 > > Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > > [] (unwind_backtrace) from [] (show_stack+0x10/0x14) > > [] (show_stack) from [] (dump_stack+0x90/0xc8) > > [] (dump_stack) from [] (__warn+0xf8/0x124) > > [] (__warn) from [] (warn_slowpath_null+0x40/0x48) > > [] (warn_slowpath_null) from [] (__i2c_transfer+0x6f8/0xa50) > > [] (__i2c_transfer) from [] (i2c_transfer+0x70/0xe4) > > [] (i2c_transfer) from [] (regmap_i2c_read+0x48/0x64) > > [] (regmap_i2c_read) from [] (_regmap_raw_read+0xf8/0x450) > > [] (_regmap_raw_read) from [] (_regmap_bus_read+0x38/0x68) > > [] (_regmap_bus_read) from [] (_regmap_read+0x60/0x250) > > [] (_regmap_read) from [] (regmap_read+0x3c/0x5c) > > [] (regmap_read) from [] (regulator_is_enabled_regmap+0x20/0x90) > > [] (regulator_is_enabled_regmap) from [] (_regulator_is_enabled+0x34/0x40) > > [] (_regulator_is_enabled) from [] (create_regulator+0x1a4/0x25c) > > [] (create_regulator) from [] (_regulator_get+0xe4/0x278) > > [] (_regulator_get) from [] (dev_pm_opp_set_regulators+0xa0/0x1c0) > > [] (dev_pm_opp_set_regulators) from [] (cpufreq_init+0x98/0x2d0) > > [] (cpufreq_init) from [] (cpufreq_online+0xc8/0x71c) > > [] (cpufreq_online) from [] (cpuhp_cpufreq_online+0x8/0x10) > > [] (cpuhp_cpufreq_online) from [] (cpuhp_invoke_callback+0xf4/0xebc) > > [] (cpuhp_invoke_callback) from [] (cpuhp_thread_fun+0x1d8/0x320) > > [] (cpuhp_thread_fun) from [] (smpboot_thread_fn+0x194/0x340) > > [] (smpboot_thread_fn) from [] (kthread+0x124/0x160) > > [] (kthread) from [] (ret_from_fork+0x14/0x20) > > Exception stack(0xe897dfb0 to 0xe897dff8) > > dfa0: 00000000 00000000 00000000 00000000 > > dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > > dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 > > irq event stamp: 3865 > > hardirqs last enabled at (3873): [] vprintk_emit+0x228/0x2a4 > > hardirqs last disabled at (3880): [] vprintk_emit+0x12c/0x2a4 > > softirqs last enabled at (3052): [] __do_softirq+0x3a4/0x66c > > softirqs last disabled at (3043): [] irq_exit+0x140/0x168 > > ---[ end trace db48b455d924fec2 ]--- > > CPU4 is up > > CPU5 is up > > CPU6 is up > > CPU7 is up > > --->8--- > > > > This is a scenario that triggers the above issue: > > > > 1. system disables non-boot cpu's at the end of system suspend procedure, > > 2. this in turn deinitializes cpufreq drivers for the disabled cpus, > > 3. early in the system resume procedure all cpus are got back to online > > state, > > 4. this in turn causes cpufreq to be initialized for the newly onlined > > cpus, > > 5. cpufreq-dt acquires all its resources (clocks, regulators) during > > ->init() callback, > > 6. getting regulator require to check its state, what in turn requires > > i2c transfer, > > 7. during system early resume stage this is not really possible. > > > > The issue is caused by cpufreq-dt driver not keeping its resources for > > the whole driver lifetime and relying that they can be always acquired > > at any system context. This problem has been observed on Samsung > > Exynos based Odroid XU3/XU4 boards, but it happens on all boards, which > > have separate regulators for different CPU clusters. > > Why don't you get similar problem during suspend? I think you can get > it when the CPUs are offlined as I2C would have gone by then. The > cpufreq or OPP core can try and run some regulator or genpd or clk > calls to disable resources, etc. Even if doesn't happen, it certainly > can. > > Also at resume the cpufreq core may try to change the frequency right > from ->init() on certain cases, though not everytime and so the > problem can come despite of this series. > > We guarantee that the resources are available during probe but not > during resume, that's where the problem is. > > @Rafael any suggestions on how to fix this ? There are cpufreq driver suspend and resume callbacks, maybe use them? The driver could do the I2C transactions in its suspend/resume callbacks and do nothing in online/offline if those are part of system-wide suspend/resume.