Re: Re: Re: Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
Am Dienstag, 5. Juli 2022, 03:24:33 CEST schrieb Saravana Kannan:
> On Mon, Jul 4, 2022 at 12:07 AM Alexander Stein
>
> wrote:
> > Am Freitag, 1. Juli 2022, 09:02:22 CEST schrieb Saravana Kannan:
> > > On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein
> > >
> > > wrote:
> > > > Hi Saravana,
> > > >
> > > > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> > > > > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
> > > > >
> > > > > wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > > > > > Hi,
> > > > > > >
> > > > > > > * Saravana Kannan [700101 02:00]:
> > > > > > > > Now that fw_devlink=on by default and fw_devlink supports
> > > > > > > > "power-domains" property, the execution will never get to the
> > > > > > > > point
> > > > > > > > where driver_deferred_probe_check_state() is called before the
> > > > > > > > supplier
> > > > > > > > has probed successfully or before deferred probe timeout has
> > > > > > > > expired.
> > > > > > > >
> > > > > > > > So, delete the call and replace it with -ENODEV.
> > > > > > >
> > > > > > > Looks like this causes omaps to not boot in Linux next. With
> > > > > > > this
> > > > > > > simple-pm-bus fails to probe initially as the power-domain is
> > > > > > > not
> > > > > > > yet available. On platform_probe() genpd_get_from_provider()
> > > > > > > returns
> > > > > > > -ENOENT.
> > > > > > >
> > > > > > > Seems like other stuff is potentially broken too, any ideas on
> > > > > > > how to fix this?
> > > > > >
> > > > > > I think I'm hit by this as well, although I do not get a lockup.
> > > > > > In my case I'm using
> > > > > > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and
> > > > > > probing of
> > > > > > 3832.blk-ctrl fails as the power-domain is not (yet) registed.
> > > > >
> > > > > Ok, took a look.
> > > > >
> > > > > The problem is that there are two drivers for the same device and
> > > > > they
> > > > > both initialize this device.
> > > > >
> > > > > gpc: gpc@303a {
> > > > >
> > > > > compatible = "fsl,imx8mq-gpc";
> > > > >
> > > > > }
> > > > >
> > > > > $ git grep -l "fsl,imx7d-gpc" -- drivers/
> > > > > drivers/irqchip/irq-imx-gpcv2.c
> > > > > drivers/soc/imx/gpcv2.c
> > > > >
> > > > > IMHO, this is a bad/broken design.
> > > > >
> > > > > So what's happening is that fw_devlink will block the probe of
> > > > > 3832.blk-ctrl until 303a.gpc is initialized. And it stops
> > > > > blocking the probe of 3832.blk-ctrl as soon as the first driver
> > > > > initializes the device. In this case, it's the irqchip driver.
> > > > >
> > > > > I'd recommend combining these drivers into one. Something like the
> > > > > patch I'm attaching (sorry for the attachment, copy-paste is
> > > > > mangling
> > > > > the tabs). Can you give it a shot please?
> > > >
> > > > I tried this patch and it delayed the driver initialization (those of
> > > > UART
> > > > as
> > >
> > > > well BTW). Unfortunately the driver fails the same way:
> > > Thanks for testing the patch!
> > >
> > > > > [1.125253] imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV:
> > > > > failed
> > > > > to
> > > >
> > > > attach power domain "bus"
> > > >
> > > > More than that it even introduced some more errors:
> > > > > [0.008160] irq: no irq domain found for gpc@303a !
> > >
> > > So the idea behind my change was that as long as the irqchip isn't the
> > > root o
Re: (EXT) Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
Am Freitag, 1. Juli 2022, 09:02:22 CEST schrieb Saravana Kannan:
> On Thu, Jun 30, 2022 at 11:02 PM Alexander Stein
>
> wrote:
> > Hi Saravana,
> >
> > Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> > > On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
> > >
> > > wrote:
> > > > Hi,
> > > >
> > > > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > > > Hi,
> > > > >
> > > > > * Saravana Kannan [700101 02:00]:
> > > > > > Now that fw_devlink=on by default and fw_devlink supports
> > > > > > "power-domains" property, the execution will never get to the
> > > > > > point
> > > > > > where driver_deferred_probe_check_state() is called before the
> > > > > > supplier
> > > > > > has probed successfully or before deferred probe timeout has
> > > > > > expired.
> > > > > >
> > > > > > So, delete the call and replace it with -ENODEV.
> > > > >
> > > > > Looks like this causes omaps to not boot in Linux next. With this
> > > > > simple-pm-bus fails to probe initially as the power-domain is not
> > > > > yet available. On platform_probe() genpd_get_from_provider() returns
> > > > > -ENOENT.
> > > > >
> > > > > Seems like other stuff is potentially broken too, any ideas on
> > > > > how to fix this?
> > > >
> > > > I think I'm hit by this as well, although I do not get a lockup.
> > > > In my case I'm using
> > > > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and probing of
> > > > 3832.blk-ctrl fails as the power-domain is not (yet) registed.
> > >
> > > Ok, took a look.
> > >
> > > The problem is that there are two drivers for the same device and they
> > > both initialize this device.
> > >
> > > gpc: gpc@303a {
> > >
> > > compatible = "fsl,imx8mq-gpc";
> > >
> > > }
> > >
> > > $ git grep -l "fsl,imx7d-gpc" -- drivers/
> > > drivers/irqchip/irq-imx-gpcv2.c
> > > drivers/soc/imx/gpcv2.c
> > >
> > > IMHO, this is a bad/broken design.
> > >
> > > So what's happening is that fw_devlink will block the probe of
> > > 3832.blk-ctrl until 303a.gpc is initialized. And it stops
> > > blocking the probe of 3832.blk-ctrl as soon as the first driver
> > > initializes the device. In this case, it's the irqchip driver.
> > >
> > > I'd recommend combining these drivers into one. Something like the
> > > patch I'm attaching (sorry for the attachment, copy-paste is mangling
> > > the tabs). Can you give it a shot please?
> >
> > I tried this patch and it delayed the driver initialization (those of UART
> > as
> > well BTW). Unfortunately the driver fails the same way:
> Thanks for testing the patch!
>
> > > [1.125253] imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV: failed
> > > to
> >
> > attach power domain "bus"
> >
> > More than that it even introduced some more errors:
> > > [0.008160] irq: no irq domain found for gpc@303a !
>
> So the idea behind my change was that as long as the irqchip isn't the
> root of the irqdomain (might be using the terms incorrectly) like the
> gic, you can make it a platform driver. And I was trying to hack up a
> patch that's the equivalent of platform_irqchip_probe() (which just
> ends up eventually calling the callback you use in IRQCHIP_DECLARE().
> I probably made some mistake in the quick hack that I'm sure if
> fixable.
>
> > > [0.013251] Failed to map interrupt for
> > > /soc@0/bus@3040/timer@306a
>
> However, this timer driver also uses TIMER_OF_DECLARE() which can't
> handle failure to get the IRQ (because it's can't -EPROBE_DEFER). So,
> this means, the timer driver inturn needs to be converted to a
> platform driver if it's supposed to work with the IRQCHIP_DECLARE()
> being converted to a platform driver.
>
> But that's a can of worms not worth opening. But then I remembered
> this simpler workaround will work and it is pretty much a variant of
> the workaround that's already in the gpc's irqchip driver to allow two
> drivers to probe the same device (people really should stop doing
> that).
>
> Can y
Re: (EXT) Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
Hi Saravana,
Am Freitag, 1. Juli 2022, 02:37:14 CEST schrieb Saravana Kannan:
> On Thu, Jun 23, 2022 at 5:08 AM Alexander Stein
>
> wrote:
> > Hi,
> >
> > Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren:
> > > Hi,
> > >
> > > * Saravana Kannan [700101 02:00]:
> > > > Now that fw_devlink=on by default and fw_devlink supports
> > > > "power-domains" property, the execution will never get to the point
> > > > where driver_deferred_probe_check_state() is called before the
> > > > supplier
> > > > has probed successfully or before deferred probe timeout has expired.
> > > >
> > > > So, delete the call and replace it with -ENODEV.
> > >
> > > Looks like this causes omaps to not boot in Linux next. With this
> > > simple-pm-bus fails to probe initially as the power-domain is not
> > > yet available. On platform_probe() genpd_get_from_provider() returns
> > > -ENOENT.
> > >
> > > Seems like other stuff is potentially broken too, any ideas on
> > > how to fix this?
> >
> > I think I'm hit by this as well, although I do not get a lockup.
> > In my case I'm using
> > arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and probing of
> > 3832.blk-ctrl fails as the power-domain is not (yet) registed.
>
> Ok, took a look.
>
> The problem is that there are two drivers for the same device and they
> both initialize this device.
>
> gpc: gpc@303a {
> compatible = "fsl,imx8mq-gpc";
> }
>
> $ git grep -l "fsl,imx7d-gpc" -- drivers/
> drivers/irqchip/irq-imx-gpcv2.c
> drivers/soc/imx/gpcv2.c
>
> IMHO, this is a bad/broken design.
>
> So what's happening is that fw_devlink will block the probe of
> 3832.blk-ctrl until 303a.gpc is initialized. And it stops
> blocking the probe of 3832.blk-ctrl as soon as the first driver
> initializes the device. In this case, it's the irqchip driver.
>
> I'd recommend combining these drivers into one. Something like the
> patch I'm attaching (sorry for the attachment, copy-paste is mangling
> the tabs). Can you give it a shot please?
I tried this patch and it delayed the driver initialization (those of UART as
well BTW). Unfortunately the driver fails the same way:
> [1.125253] imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV: failed to
attach power domain "bus"
More than that it even introduced some more errors:
> [0.008160] irq: no irq domain found for gpc@303a !
> [0.013251] Failed to map interrupt for
> /soc@0/bus@3040/timer@306a
> [0.020152] Failed to initialize '/soc@0/bus@3040/timer@306a':
> -22
I kept the timestamps to show that these errors happen very early. So now the
usage of the "global" interrupt parent, set at line 18,
> interrupt-parent = <>;
is not possible at this point of boot time.
Best regards,
Alexander
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state()
Hi, Am Dienstag, 21. Juni 2022, 09:28:43 CEST schrieb Tony Lindgren: > Hi, > > * Saravana Kannan [700101 02:00]: > > Now that fw_devlink=on by default and fw_devlink supports > > "power-domains" property, the execution will never get to the point > > where driver_deferred_probe_check_state() is called before the supplier > > has probed successfully or before deferred probe timeout has expired. > > > > So, delete the call and replace it with -ENODEV. > > Looks like this causes omaps to not boot in Linux next. With this > simple-pm-bus fails to probe initially as the power-domain is not > yet available. On platform_probe() genpd_get_from_provider() returns > -ENOENT. > > Seems like other stuff is potentially broken too, any ideas on > how to fix this? I think I'm hit by this as well, although I do not get a lockup. In my case I'm using arch/arm64/boot/dts/freescale/imx8mq-tqma8mq-mba8mx.dts and probing of 3832.blk-ctrl fails as the power-domain is not (yet) registed. See the (filtered) dmesg output: > [0.744245] PM: Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@0 [0.744756] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@2 [0.745012] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@3 [0.745268] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@4 [0.746121] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@7 [0.746400] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@8 [0.746665] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@9 [0.746927] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@a [0.748870] > imx8m-blk-ctrl 3832.blk-ctrl: error -ENODEV: failed to attach bus power > domain [1.265279] PM: Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@5 [1.265861] PM: > Added domain provider from > /soc@0/bus@3000/gpc@303a/pgc/power-domain@6 blk-ctrl@3832 requires the power-domain 'pgc_vpu', which is power-domain@6 in pgc. Best regards, Alexander > > Signed-off-by: Saravana Kannan > > --- > > > > drivers/base/power/domain.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > index 739e52cd4aba..3e86772d5fac 100644 > > --- a/drivers/base/power/domain.c > > +++ b/drivers/base/power/domain.c > > @@ -2730,7 +2730,7 @@ static int __genpd_dev_pm_attach(struct device *dev, > > struct device *base_dev,> > > mutex_unlock(_list_lock); > > dev_dbg(dev, "%s() failed to find PM domain: %ld\n", > > > > __func__, PTR_ERR(pd)); > > > > - return driver_deferred_probe_check_state(base_dev); > > + return -ENODEV; > > > > } > > > > dev_dbg(dev, "adding to PM domain %s\n", pd->name); ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/1] dma-direct: Fix dma_direct_use_pool helper
During refactoring the logic around gfpflags_allow_blocking() got inverted
due to missing '!'. Fix this by adding it back.
Fixes: 8d7c141bb80f ("dma-direct: add a dma_direct_use_pool helper")
Signed-off-by: Alexander Stein
---
I bisected this to the commit in 'Fixed:' tag. Here is the splat:
[ cut here ]
Failed to get suitable pool for 30be.ethernet
WARNING: CPU: 0 PID: 62 at kernel/dma/pool.c:279 dma_alloc_from_pool+0x88/0x1d0
Modules linked in:
CPU: 0 PID: 62 Comm: kworker/u8:2 Not tainted 5.16.0-rc4-tq+ #238
Hardware name: TQ-Systems GmbH i.MX8MQ TQMa8MQ on MBa8Mx (DT)
Workqueue: events_unbound deferred_probe_work_func
pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : dma_alloc_from_pool+0x88/0x1d0
lr : dma_alloc_from_pool+0x88/0x1d0
sp : 8000126b3860
x29: 8000126b3860 x28: 800012133d68 x27:
x26: c03e x25: 8000126b3930 x24: c08ee010
x23: 800012133d48 x22: 80001011f4b0 x21: 800011712820
x20: 00018000 x19: c0ef8000 x18: 0014
x17: 756420676e697375 x16: 202c646e756f6620 x15:
x14: x13: 20726f66206c6f6f x12: 7020656c62617469
x11: 6568207475
