From: Pi-Hsun Shih <pihsun@chromium.org> To: Matthias Brugger <matthias.bgg@gmail.com> Cc: "Youlin Pei (裴友林)" <youlin.pei@mediatek.com>, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" <devicetree@vger.kernel.org>, "Nicolas Boichat" <drinkcat@chromium.org>, srv_heupstream@mediatek.com, "Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will.deacon@arm.com>, "open list" <linux-kernel@vger.kernel.org>, "Evan Green" <evgreen@chromium.org>, "Tomasz Figa" <tfiga@google.com>, iommu@lists.linux-foundation.org, "Rob Herring" <robh+dt@kernel.org>, "moderated list:ARM/Mediatek SoC support" <linux-mediatek@lists.infradead.org>, "moderated list:ARM/Mediatek SoC support" <linux-arm-kernel@lists.infradead.org>, "Sascha Hauer" <kernel@pengutronix.de>, "Yingjoe Chen (陳英洲)" <yingjoe.chen@mediatek.com>, anan.sun@mediatek.com, "Robin Murphy" <robin.murphy@arm.com>, "Matthias Kaehlcke" <mka@chromium.org>, "Yong Wu" <yong.wu@mediatek.com> Subject: Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183 Date: Fri, 21 Jun 2019 11:57:01 +0800 Message-ID: <CANdKZ0cr=SMtQOTVduKZBOtw5E6ZOpShf3q2McDX=rFWbfB03A@mail.gmail.com> (raw) In-Reply-To: <effb4fff-da83-708f-ca10-50f2645c91c6@gmail.com> On Thu, Jun 20, 2019 at 7:38 PM Matthias Brugger <matthias.bgg@gmail.com> wrote: > > CCing Sascha > > On 20/06/2019 11:35, Matthias Brugger wrote: > > > > > > On 13/06/2019 10:14, Pi-Hsun Shih wrote: > >> Hi, > >> When I tested this patch series (Based on linux 5.2.0-rc2, and with > >> various other patch series about MT8183) with lockdep enabled, and I'm > >> seeing the following lockdep warning on boot. > >> > >> By bisecting the commits, the first commit that introduce this warning > >> is this patch. The warning also doesn't appear if > >> https://lore.kernel.org/patchwork/patch/1086582/ and > >> https://lore.kernel.org/patchwork/patch/1086583/ are not applied. > >> > >> Do anyone have idea on why this is happening, or any suggestion on > >> which part I should be digging into to figure this out? Thanks. > >> > >> [ 4.664194] ====================================================== > >> [ 4.670368] WARNING: possible circular locking dependency detected > >> [ 4.676545] 5.2.0-rc2-next-20190528-44527-g6c94b6475c04 #20 Tainted: G S > >> [ 4.684539] ------------------------------------------------------ > >> [ 4.690714] kworker/4:1/51 is trying to acquire lock: > >> [ 4.695760] (____ptrval____) (regulator_list_mutex){+.+.}, > >> at:regulator_lock_dependent+0xdc/0x6c4 > >> [ 4.704732] > >> [ 4.704732] but task is already holding lock: > >> [ 4.710556] (____ptrval____) (&genpd->mlock/1){+.+.}, > >> at:genpd_lock_nested_mtx+0x24/0x30 > >> [ 4.718740] > >> [ 4.718740] which lock already depends on the new lock. > >> [ 4.718740] > >> [ 4.726908] > >> [ 4.726908] the existing dependency chain (in reverse order) is: > >> [ 4.734382] > >> [ 4.734382] -> #4 (&genpd->mlock/1){+.+.}: > >> [ 4.739963] __mutex_lock_common+0x1a0/0x1fe8 > >> [ 4.744836] mutex_lock_nested+0x40/0x50 > >> [ 4.749275] genpd_lock_nested_mtx+0x24/0x30 > >> [ 4.754063] genpd_add_subdomain+0x150/0x524 > >> [ 4.758850] pm_genpd_add_subdomain+0x3c/0x5c > >> [ 4.763723] scpsys_probe+0x520/0xe78 > >> [ 4.767902] platform_drv_probe+0xf4/0x134 > >> [ 4.772517] really_probe+0x214/0x4dc > >> [ 4.776696] driver_probe_device+0xcc/0x1d4 > >> [ 4.781396] __device_attach_driver+0x10c/0x180 > >> [ 4.786442] bus_for_each_drv+0x124/0x184 > >> [ 4.790968] __device_attach+0x1c0/0x2d8 > >> [ 4.795407] device_initial_probe+0x20/0x2c > >> [ 4.800106] bus_probe_device+0x80/0x16c > >> [ 4.804546] deferred_probe_work_func+0x120/0x168 > >> [ 4.809767] process_one_work+0x858/0x1208 > >> [ 4.814379] worker_thread+0x9ec/0xcb8 > >> [ 4.818644] kthread+0x2b8/0x2d0 > >> [ 4.822391] ret_from_fork+0x10/0x18 > >> [ 4.826480] > >> [ 4.826480] -> #3 (&genpd->mlock){+.+.}: > >> [ 4.831880] __mutex_lock_common+0x1a0/0x1fe8 > >> [ 4.836752] mutex_lock_nested+0x40/0x50 > >> [ 4.841190] genpd_lock_mtx+0x20/0x2c > >> [ 4.845369] genpd_runtime_resume+0x140/0x434 > >> [ 4.850241] __rpm_callback+0xb0/0x1e4 > >> [ 4.854506] rpm_callback+0x54/0x1a8 > >> [ 4.858597] rpm_resume+0xc6c/0x10c4 > >> [ 4.862689] __pm_runtime_resume+0xb4/0x124 > >> [ 4.867387] device_link_add+0x598/0x8d0 > > > > For this looks as if you have also patch > > [PATCH v2 04/12] memory: mtk-smi: Add device-link between smi-larb and smi-common > > from series > > [PATCH v2 00/12] Clean up "mediatek,larb" after adding device_link > > applied. > > > > My guess is, that we run into this, because we call genpd_runtime_resume before > we have finished the subdomain registration in scpsys_probe. > That implies that you also have the scpsys series for mt8183 added to your tree. > > Anyway it looks to me as if we have to add the subdomains before we call > of_genpd_add_provider_onecell(). > > Regards, > Matthias Yes I do have scpsys series for mt8183 added in my tree. (I have about 125 patches from list on top of 531b0a360899 "Add linux-next specific files for 20190528" to make the board boot) However the exact same warning still exists after I changed the order of of_genpd_add_provider_onecell and pm_genpd_add_subdomain, patch as follow: (Patch is based on commit f4788d37bc84 "Add linux-next specific files for 20190614") diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c index 503222d0d0da..0cd9bdd4004e 100644 --- a/drivers/soc/mediatek/mtk-scpsys.c +++ b/drivers/soc/mediatek/mtk-scpsys.c @@ -440,8 +440,7 @@ static struct scp *init_scp(struct platform_device *pdev, static void mtk_register_power_domains(struct platform_device *pdev, struct scp *scp, int num) { - struct genpd_onecell_data *pd_data; - int i, ret; + int i; for (i = 0; i < num; i++) { struct scp_domain *scpd = &scp->domains[i]; @@ -457,18 +456,6 @@ static void mtk_register_power_domains(struct platform_device *pdev, pm_genpd_init(genpd, NULL, false); } - - /* - * We are not allowed to fail here since there is no way to unregister - * a power domain. Once registered above we have to keep the domains - * valid. - */ - - pd_data = &scp->pd_data; - - ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data); - if (ret) - dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret); } /* @@ -1053,6 +1040,16 @@ static int scpsys_probe(struct platform_device *pdev) ret); } + /* + * We are not allowed to fail here since there is no way to unregister + * a power domain. Once registered above we have to keep the domains + * valid. + */ + + ret = of_genpd_add_provider_onecell(pdev->dev.of_node, pd_data); + if (ret) + dev_err(&pdev->dev, "Failed to add OF provider: %d\n", ret); + return 0; } > > > > Regards, > > Matthias > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply index Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-10 12:17 [PATCH v7 00/21] MT8183 IOMMU SUPPORT Yong Wu 2019-06-10 12:17 ` [PATCH v7 01/21] dt-bindings: mediatek: Add binding for mt8183 IOMMU and SMI Yong Wu 2019-06-10 12:17 ` [PATCH v7 02/21] iommu/mediatek: Use a struct as the platform data Yong Wu 2019-06-10 12:17 ` [PATCH v7 03/21] memory: mtk-smi: Use a general config_port interface Yong Wu 2019-06-10 12:17 ` [PATCH v7 04/21] memory: mtk-smi: Use a struct for the platform data for smi-common Yong Wu 2019-06-10 12:17 ` [PATCH v7 05/21] iommu/io-pgtable-arm-v7s: Add paddr_to_iopte and iopte_to_paddr helpers Yong Wu 2019-06-10 12:17 ` [PATCH v7 06/21] iommu/io-pgtable-arm-v7s: Extend MediaTek 4GB Mode Yong Wu 2019-06-10 12:17 ` [PATCH v7 07/21] iommu/mediatek: Add bclk can be supported optionally Yong Wu 2019-06-15 19:18 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 08/21] iommu/mediatek: Add larb-id remapped support Yong Wu 2019-06-17 9:25 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 09/21] iommu/mediatek: Refine protect memory definition Yong Wu 2019-06-17 9:59 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 10/21] iommu/mediatek: Move reset_axi into plat_data Yong Wu 2019-06-17 10:19 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 11/21] iommu/mediatek: Move vld_pa_rng " Yong Wu 2019-06-17 10:27 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 12/21] memory: mtk-smi: Add gals support Yong Wu 2019-06-17 15:43 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 13/21] iommu/mediatek: Add mt8183 IOMMU support Yong Wu 2019-06-17 15:51 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 14/21] iommu/mediatek: Add mmu1 support Yong Wu 2019-06-17 15:58 ` Matthias Brugger 2019-06-18 6:19 ` Tomasz Figa 2019-06-18 12:09 ` Yong Wu 2019-06-18 14:05 ` Tomasz Figa 2019-06-10 12:17 ` [PATCH v7 15/21] memory: mtk-smi: Invoke pm runtime_callback to enable clocks Yong Wu 2019-06-17 16:13 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183 Yong Wu 2019-06-13 8:20 ` Pi-Hsun Shih 2019-06-17 16:28 ` Matthias Brugger 2019-06-17 16:23 ` Matthias Brugger 2019-06-18 12:10 ` Yong Wu 2019-06-18 21:07 ` Matthias Brugger [not found] ` <CANdKZ0d873PJ2u=Hn_aUJBu3dDiNyueVwBv94-VXHGLJBvAbGg@mail.gmail.com> 2019-06-20 9:35 ` Matthias Brugger 2019-06-20 11:38 ` Matthias Brugger 2019-06-21 3:57 ` Pi-Hsun Shih [this message] 2019-06-10 12:17 ` [PATCH v7 17/21] memory: mtk-smi: Get rid of need_larbid Yong Wu 2019-06-18 13:45 ` Matthias Brugger 2019-06-20 13:59 ` Yong Wu 2019-06-10 12:17 ` [PATCH v7 18/21] iommu/mediatek: Fix VLD_PA_RNG register backup when suspend Yong Wu 2019-06-17 16:30 ` Matthias Brugger 2019-06-10 12:17 ` [PATCH v7 19/21] iommu/mediatek: Rename enable_4GB to dram_is_4gb Yong Wu 2019-06-18 16:06 ` Matthias Brugger 2019-06-20 13:59 ` Yong Wu 2019-06-21 10:10 ` Matthias Brugger 2019-06-22 2:42 ` Yong Wu 2019-06-10 12:17 ` [PATCH v7 20/21] iommu/mediatek: Fix iova_to_phys PA start for 4GB mode Yong Wu 2019-06-18 16:35 ` Matthias Brugger 2019-06-20 14:00 ` Yong Wu 2019-06-10 12:18 ` [PATCH v7 21/21] iommu/mediatek: Switch to SPDX license identifier Yong Wu 2019-06-17 16:33 ` Matthias Brugger
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CANdKZ0cr=SMtQOTVduKZBOtw5E6ZOpShf3q2McDX=rFWbfB03A@mail.gmail.com' \ --to=pihsun@chromium.org \ --cc=anan.sun@mediatek.com \ --cc=devicetree@vger.kernel.org \ --cc=drinkcat@chromium.org \ --cc=evgreen@chromium.org \ --cc=iommu@lists.linux-foundation.org \ --cc=joro@8bytes.org \ --cc=kernel@pengutronix.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mediatek@lists.infradead.org \ --cc=matthias.bgg@gmail.com \ --cc=mka@chromium.org \ --cc=robh+dt@kernel.org \ --cc=robin.murphy@arm.com \ --cc=srv_heupstream@mediatek.com \ --cc=tfiga@google.com \ --cc=will.deacon@arm.com \ --cc=yingjoe.chen@mediatek.com \ --cc=yong.wu@mediatek.com \ --cc=youlin.pei@mediatek.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-ARM-Kernel Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \ linux-arm-kernel@lists.infradead.org public-inbox-index linux-arm-kernel Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git