Re: [PATCH 12/21] iommu/mediatek: Add iova reserved function
On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
>
> For multiple iommu_domains, we need to reserve some iova regions, so we
> will add mtk_iommu_iova_region structure. It includes the base address
> and size of the range.
> This is a preparing patch for supporting multi-domain.
>
> Signed-off-by: Anan sun
> Signed-off-by: Hao Chao
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 37 +
> drivers/iommu/mtk_iommu.h | 5 +
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 03a6d66f4bef..fdfdb75706e0 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -151,6 +151,11 @@ static LIST_HEAD(m4ulist); /* List all the M4U HWs */
> ...
> +
> +static void mtk_iommu_put_resv_regions(struct device *dev,
> + struct list_head *head)
> +{
> + struct iommu_resv_region *entry, *next;
> +
> + list_for_each_entry_safe(entry, next, head, list)
> + kfree(entry);
> +}
> +
This is the same as generic_iommu_put_resv_regions, use that as the
.put_resv_regions callback instead?
> ...
> --
> 2.18.0
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 11/21] iommu/mediatek: Add power-domain operation
On Sat, Jul 11, 2020 at 2:51 PM Yong Wu wrote:
>
> In the previous SoC, the M4U HW is in the EMI power domain which is
> always on. the latest M4U is in the display power domain which may be
> turned on/off, thus we have to add pm_runtime interface for it.
>
> we should enable its power before M4U hw initial. and disable it after HW
> initialize.
>
> When the engine work, the engine always enable the power and clocks for
> smi-larb/smi-common, then the M4U's power will always be powered on
> automatically via the device link with smi-common.
>
> Note: we don't enable the M4U power in iommu_map/unmap for tlb flush.
> If its power already is on, of course it is ok. if the power is off,
> the main tlb will be reset while M4U power on, thus the tlb flush while
> m4u power off is unnecessary, just skip it.
>
> Signed-off-by: Yong Wu
> ---
> drivers/iommu/mtk_iommu.c | 54 ++-
> 1 file changed, 47 insertions(+), 7 deletions(-)
> ...
> for_each_m4u(data) {
> + /* skip tlb flush when pm is not active */
> + if (pm_runtime_enabled(data->dev) &&
> + !pm_runtime_active(data->dev))
> + continue;
> +
pm_runtime_active(dev) == false implies dev->power.disable_depth == 0,
which implies pm_runtime_enabled(dev) == true, so the
pm_runtime_enabled(data->dev) can be omitted here.
> spin_lock_irqsave(&data->tlb_lock, flags);
> writel_relaxed(F_INVLD_EN1 | F_INVLD_EN0,
>data->base + data->plat_data->inv_sel_reg);
> ...
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/21] dt-binding: memory: mediatek: Add a common larb-port header file
On Mon, Jul 13, 2020 at 2:06 AM Matthias Brugger wrote: > > > > On 11/07/2020 08:48, Yong Wu wrote: > > Put all the macros about smi larb/port togethers, this is a preparing > > patch for extending LARB_NR and adding new dom-id support. > > > > Signed-off-by: Yong Wu > > --- > > include/dt-bindings/memory/mt2712-larb-port.h | 2 +- > > include/dt-bindings/memory/mt6779-larb-port.h | 2 +- > > include/dt-bindings/memory/mt8173-larb-port.h | 2 +- > > include/dt-bindings/memory/mt8183-larb-port.h | 2 +- > > include/dt-bindings/memory/mtk-smi-larb-port.h | 15 +++ > > 5 files changed, 19 insertions(+), 4 deletions(-) > > create mode 100644 include/dt-bindings/memory/mtk-smi-larb-port.h > > > > ... > > diff --git a/include/dt-bindings/memory/mtk-smi-larb-port.h > > b/include/dt-bindings/memory/mtk-smi-larb-port.h > > new file mode 100644 > > index ..2ec7fe5ce4e9 > > --- /dev/null > > +++ b/include/dt-bindings/memory/mtk-smi-larb-port.h > > @@ -0,0 +1,15 @@ > > +/* SPDX-License-Identifier: GPL-2.0-only */ > > +/* > > + * Copyright (c) 2020 MediaTek Inc. > > + * Author: Yong Wu > > + */ > > +#ifndef __DTS_MTK_IOMMU_PORT_H_ > > +#define __DTS_MTK_IOMMU_PORT_H_ > > + > > +#define MTK_LARB_NR_MAX 16 > > include/soc/mediatek/smi.h has the very same define. > Should smi.h include this file? > > Regards, > Matthias > Looks like this is being addressed in patch 5 in this series ([05/21] iommu/mediatek: Use the common mtk-smi-larb-port.h) That said, should that patch be merged into this one? > > + > > +#define MTK_M4U_ID(larb, port) (((larb) << 5) | (port)) > > +#define MTK_M4U_TO_LARB(id) (((id) >> 5) & 0xf) > > +#define MTK_M4U_TO_PORT(id) ((id) & 0x1f) > > + > > +#endif > > ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 04/21] dt-binding: mediatek: Add binding for mt8192 IOMMU and SMI
On Sat, Jul 11, 2020 at 2:50 PM Yong Wu wrote: > > This patch adds decriptions for mt8192 IOMMU and SMI. > > mt8192 also is MTK IOMMU gen2 which uses ARM Short-Descriptor translation > table format. The M4U-SMI HW diagram is as below: > > EMI >| > M4U >| > >SMI Common > >| > +---+--+--+--+---+ > | | | | .. | | > | | | | | | > larb0 larb1 larb2 larb4 .. larb19 larb20 > disp0 disp1 mdpvdec IPE IPE > > All the connections are HW fixed, SW can NOT adjust it. > > mt8192 M4U support 0~16GB iova range. we preassign different engines > into different iova ranges: > > domain-id module iova-range larbs >0 disp0 ~ 4G larb0/1 >1 vcodec 4G ~ 8G larb4/5/7 >2 cam/mdp 8G ~ 12G larb2/9/11/13/14/16/17/18/19/20 >3 CCU00x4000_ ~ 0x43ff_ larb13: port 9/10 >4 CCU10x4400_ ~ 0x47ff_ larb14: port 4/5 > > The iova range for CCU0/1(camera control unit) is HW requirement. > > Signed-off-by: Yong Wu > --- > .../bindings/iommu/mediatek,iommu.txt | 8 +- > .../mediatek,smi-common.txt | 5 +- > .../memory-controllers/mediatek,smi-larb.txt | 3 +- > include/dt-bindings/memory/mt8192-larb-port.h | 237 ++ > 4 files changed, 247 insertions(+), 6 deletions(-) > create mode 100644 include/dt-bindings/memory/mt8192-larb-port.h > ... > diff --git a/include/dt-bindings/memory/mt8192-larb-port.h > b/include/dt-bindings/memory/mt8192-larb-port.h > new file mode 100644 > index ..fbe0d5d50f1c > --- /dev/null > +++ b/include/dt-bindings/memory/mt8192-larb-port.h > ... > +/* larb7 */ > +#define M4U_PORT_L7_VENC_RCPU MTK_M4U_DOM_ID(1, 7, 0) > +#define M4U_PORT_L7_VENC_REC MTK_M4U_DOM_ID(1, 7, 1) > +#define M4U_PORT_L7_VENC_BSDMA MTK_M4U_DOM_ID(1, 7, 2) > +#define M4U_PORT_L7_VENC_SV_COMV MTK_M4U_DOM_ID(1, 7, 3) > +#define M4U_PORT_L7_VENC_RD_COMV MTK_M4U_DOM_ID(1, 7, 4) > +#define M4U_PORT_L7_VENC_CUR_LUMA MTK_M4U_DOM_ID(1, 7, 5) > +#define M4U_PORT_L7_VENC_CUR_CHROMAMTK_M4U_DOM_ID(1, 7, 6) > +#define M4U_PORT_L7_VENC_REF_LUMA MTK_M4U_DOM_ID(1, 7, 7) > +#define M4U_PORT_L7_VENC_REF_CHROMAMTK_M4U_DOM_ID(1, 7, 8) > +#define M4U_PORT_L7_JPGENC_Y_RDMA MTK_M4U_DOM_ID(1, 7, 9) > +#define M4U_PORT_L7_JPGENC_Q_RDMA MTK_M4U_DOM_ID(1, 7, 10) > +#define M4U_PORT_L7_JPGENC_C_TABLE MTK_M4U_DOM_ID(1, 7, 11) > +#define M4U_PORT_L7_JPGENC_BSDMA MTK_M4U_DOM_ID(1, 7, 12) > +#define M4U_PORT_L7_VENC_SUB_R_LUMAMTK_M4U_DOM_ID(1, 7, 13) > +#define M4U_PORT_L7_VENC_SUB_W_LUMAMTK_M4U_DOM_ID(1, 7, 14) > + Small nit, /* larb8: null */ is missing here. > +/* larb9 */ > +#define M4U_PORT_L9_IMG_IMGI_D1MTK_M4U_DOM_ID(2, 9, > 0) > +#define M4U_PORT_L9_IMG_IMGBI_D1 MTK_M4U_DOM_ID(2, 9, 1) > +#define M4U_PORT_L9_IMG_DMGI_D1MTK_M4U_DOM_ID(2, 9, > 2) > +#define M4U_PORT_L9_IMG_DEPI_D1MTK_M4U_DOM_ID(2, 9, > 3) > +#define M4U_PORT_L9_IMG_ICE_D1 MTK_M4U_DOM_ID(2, 9, 4) > +#define M4U_PORT_L9_IMG_SMTI_D1MTK_M4U_DOM_ID(2, 9, > 5) > +#define M4U_PORT_L9_IMG_SMTO_D2MTK_M4U_DOM_ID(2, 9, > 6) > +#define M4U_PORT_L9_IMG_SMTO_D1MTK_M4U_DOM_ID(2, 9, > 7) > +#define M4U_PORT_L9_IMG_CRZO_D1MTK_M4U_DOM_ID(2, 9, > 8) > +#define M4U_PORT_L9_IMG_IMG3O_D1 MTK_M4U_DOM_ID(2, 9, 9) > +#define M4U_PORT_L9_IMG_VIPI_D1MTK_M4U_DOM_ID(2, 9, > 10) > +#define M4U_PORT_L9_IMG_SMTI_D5MTK_M4U_DOM_ID(2, 9, > 11) > +#define M4U_PORT_L9_IMG_TIMGO_D1 MTK_M4U_DOM_ID(2, 9, 12) > +#define M4U_PORT_L9_IMG_UFBC_W0MTK_M4U_DOM_ID(2, 9, > 13) > +#define M4U_PORT_L9_IMG_UFBC_R0MTK_M4U_DOM_ID(2, 9, > 14) > + > ... ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
On Thu, Jun 20, 2019 at 7:38 PM Matthias Brugger 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_
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
(Sorry for the possibly double-posting, my last mail got rejected by
some mailing lists.)
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
[4.871829]mtk_smi_larb_probe+0x2b0/0x340
[4.876528]platform_drv_probe+0xf4/0x134
[4.881141]really_probe+0x214/0x4dc
[4.885320]driver_probe_device+0xcc/0x1d4
[4.890020]__device_attach_driver+0x10c/0x180
[4.895066]bus_for_each_drv+0x124/0x184
[4.899591]__device_attach+0x1c0/0x2d8
[4.904031]device_initial_probe+0x20/0x2c
[4.908730]bus_probe_device+0x80/0x16c
[4.913169]deferred_probe_work_func+0x120/0x168
[4.918387]process_one_work+0x858/0x1208
[4.923000]worker_thread+0x9ec/0xcb8
[4.927264]kthread+0x2b8/0x2d0
[4.931009]ret_from_fork+0x10/0x18
[4.935098]
[4.935098] -> #2 (dpm_list_mtx){+.+.}:
[4.940412]__mutex_lock_common+0x1a0/0x1fe8
[4.945284]mutex_lock_nested+0x40/0x50
[4.949722]device_pm_lock+0x1c/0x24
[4.953900]device_link_add+0x98/0x8d0
[4.958252]_regulator_get+0x3f0/0x504
[4.962606]_devm_regulator_get+0x58/0xb8
[4.967218]devm_regulator_get+0x28/0x34
[4.971746]pwm_backlight_probe+0x61c/0x1b90
[4.976617]platform_drv_probe+0xf4/0x134
[4.981230]really_probe+0x214/0x4dc
[4.985409]driver_probe_device+0xcc/0x1d4
[4.990108]device_driver_attach+0xe4/0x104
[4.994894]__driver_attach+0x134/0x14c
[4.999333]bus_for_each_dev+0x120/0x180
[5.003859]driver_attach+0x48/0x54
[5.007950]bus_add_driver+0x2ac/0x44c
[5.012303]driver_register+0x160/0x288
[5.016742]__platform_driver_register+0xcc/0xdc
[5.021964]pwm_backlight_driver_init+0x1c/0x24
[5.027097]do_one_initcall+0x38c/0x994
[5.031536]do_initcall_level+0x3a4/0x4b8
[5.036148]do_basic_setup+0x84/0xa0
[5.036153]kernel_init_freeable+0x23c/0x324
[5.036158]kernel_init+0x14/0x110
[5.036164]ret_from_
Re: [PATCH v7 16/21] memory: mtk-smi: Add bus_sel for mt8183
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
[4.871829]mtk_smi_larb_probe+0x2b0/0x340
[4.876528]platform_drv_probe+0xf4/0x134
[4.881141]really_probe+0x214/0x4dc
[4.885320]driver_probe_device+0xcc/0x1d4
[4.890020]__device_attach_driver+0x10c/0x180
[4.895066]bus_for_each_drv+0x124/0x184
[4.899591]__device_attach+0x1c0/0x2d8
[4.904031]device_initial_probe+0x20/0x2c
[4.908730]bus_probe_device+0x80/0x16c
[4.913169]deferred_probe_work_func+0x120/0x168
[4.918387]process_one_work+0x858/0x1208
[4.923000]worker_thread+0x9ec/0xcb8
[4.927264]kthread+0x2b8/0x2d0
[4.931009]ret_from_fork+0x10/0x18
[4.935098]
[4.935098] -> #2 (dpm_list_mtx){+.+.}:
[4.940412]__mutex_lock_common+0x1a0/0x1fe8
[4.945284]mutex_lock_nested+0x40/0x50
[4.949722]device_pm_lock+0x1c/0x24
[4.953900]device_link_add+0x98/0x8d0
[4.958252]_regulator_get+0x3f0/0x504
[4.962606]_devm_regulator_get+0x58/0xb8
[4.967218]devm_regulator_get+0x28/0x34
[4.971746]pwm_backlight_probe+0x61c/0x1b90
[4.976617]platform_drv_probe+0xf4/0x134
[4.981230]really_probe+0x214/0x4dc
[4.985409]driver_probe_device+0xcc/0x1d4
[4.990108]device_driver_attach+0xe4/0x104
[4.994894]__driver_attach+0x134/0x14c
[4.999333]bus_for_each_dev+0x120/0x180
[5.003859]driver_attach+0x48/0x54
[5.007950]bus_add_driver+0x2ac/0x44c
[5.012303]driver_register+0x160/0x288
[5.016742]__platform_driver_register+0xcc/0xdc
[5.021964]pwm_backlight_driver_init+0x1c/0x24
[5.027097]do_one_initcall+0x38c/0x994
[5.031536]do_initcall_level+0x3a4/0x4b8
[5.036148]do_basic_setup+0x84/0xa0
[5.036153]kernel_init_freeable+0x23c/0x324
[5.036158]kernel_init+0x14/0x110
[5.036164]ret_from_fork+0x10/0x18
[5.036166]
[5.036166] -> #1 (device_links_lock){+.+.}:
[5.065905
