Re: dma_declare_coherent_memory on main memory
On Fri, Dec 07, 2018 at 04:34:32PM +0100, Christoph Hellwig wrote: > Hi all, > > the ARM imx27/31 ports and various sh boards use > dma_declare_coherent_memory on main memory taken from the memblock > allocator. > > Is there any good reason these couldn't be switched to CMA areas? > Getting rid of these magic dma_declare_coherent_memory area would > help making the dma allocator a lot simpler. At least for i.MX27/31 I'd say this predates CMA support, so historical reasons. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
> On 04/11/2012 06:10 AM, Thierry Reding wrote:
> > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > currently has rudimentary GEM support and can run a console on the
> > framebuffer as well as X using the xf86-video-modesetting driver.
> > Only the RGB output is supported. Quite a lot of things still need
> > to be worked out and there is a lot of room for cleanup.
>
> I'll let Jon Mayo comment on the actual driver implementation, since
> he's a lot more familiar with Tegra's display hardware. However, I have
> some general comments below.
>
> > .../devicetree/bindings/gpu/drm/tegra.txt | 24 +
> > arch/arm/mach-tegra/board-dt-tegra20.c |3 +
> > arch/arm/mach-tegra/tegra2_clocks.c|8 +-
> > drivers/gpu/drm/Kconfig|2 +
> > drivers/gpu/drm/Makefile |1 +
> > drivers/gpu/drm/tegra/Kconfig | 10 +
> > drivers/gpu/drm/tegra/Makefile |5 +
> > drivers/gpu/drm/tegra/tegra_drv.c | 2241
> >
> > drivers/gpu/drm/tegra/tegra_drv.h | 184 ++
> > include/drm/tegra_drm.h| 44 +
>
> Splitting this patch into two, between arch/arm and drivers/gpu would be
> a good idea.
>
> > diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
> > b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
>
> > + drm@5420 {
> > + compatible = "nvidia,tegra20-drm";
>
> This doesn't seem right; there isn't a "DRM" hardware module on Tegra,
> since "DRM" is a Linux/software-specific term.
>
> I'd at least expect to see this compatible flag be renamed to something
> more like "nvidia,tegra20-dc" (dc==display controller).
>
> Since Tegra has two display controller modules (I believe identical?),
> and numerous other independent(?) blocks, I'd expect to see multiple
> nodes in device tree, one per hardware block, such that each block gets
> its own device and driver. That said, I'm not familiar enough with
> Tegra's display and graphics HW to know if this makes sense. Jon, what's
> your take here? The clock change below, and in particular the original
> code there that we use downstream, lends weight to my argument.
>
> > + reg = < 0x5420 0x0004/* display A */
> > + 0x5424 0x0004/* display B */
> > + 0x5800 0x0200 >; /* GART aperture */
> > + interrupts = < 0 73 0x04/* display A */
> > + 0 74 0x04 >; /* display B */
> > +
> > + lvds {
> > + type = "rgb";
>
> These sub-nodes probably want a "compatible" property rather than a
> "type" property.
>
> > + size = <345 194>;
> > +
> > + default-mode {
> > + pixel-clock = <61715000>;
> > + vertical-refresh = <50>;
> > + resolution = <1366 768>;
> > + bits-per-pixel = <16>;
> > + horizontal-timings = <4 136 2 36>;
> > + vertical-timings = <2 4 21 10>;
> > + };
> > + };
>
> I imagine that quite a bit of thought needs to be put into the output
> part of the binding in order to:
>
> * Model the outputs/connectors separately from display controllers.
> * Make sure that the basic infra-structure for representing an output is
> general enough to be extensible to all the kinds of outputs we support,
> not just the LVDS output.
> * We were wondering about putting an EDID into the DT to represent the
> display modes, so that all outputs had EDIDs rather than "real" monitors
> having EDIDs, and fixed internal displays having some other
> representation of capabilities.
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so that each of them can
have its own representation in the devicetree. I haven't looked into
devicetree support for DRM, but with or without devicetree the problem
that we do not have a single PCI card for registering all DRM components
is the same.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] drm/rockchip: Refactor IOMMU initialisation
On Tue, Apr 05, 2022 at 03:32:50PM +0100, Robin Murphy wrote: > Defer the IOMMU domain setup until after successfully binding > components, so we can figure out IOMMU support directly from the VOP > devices themselves, rather than manually inferring it from the DT (which > also fails to account for whether the IOMMU driver is actually loaded). > Although this is somewhat of a logical cleanup, the main motivation is > to prepare for a change in the iommu_domain_alloc() interface. > > Signed-off-by: Robin Murphy > --- > > Lightly tested on RK3288. This does stand to collide with the in-flight > VOP2 driver a little, if only that that will want an equivalent > rockchip_drm_dma_init_device() call too be able to use its IOMMU. I'm > happy to help sort that out either way, it just depends on what we want > to merge first. I tested it with the VOP2 driver. It needed a little refactoring, I had to move the call to rockchip_drm_dma_attach_device() from vop2_bind() to vop2_enable(), but then it works as expected. Assuming that this patch goes through Heikos tree just like the VOP2 driver we can merge it first. I'll base the next VOP2 round on it. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default
On Wed, Jun 01, 2022 at 12:07:03AM -0700, Saravana Kannan wrote:
> Now that deferred_probe_timeout is non-zero by default, fw_devlink will
> never permanently block the probing of devices. It'll try its best to
> probe the devices in the right order and then finally let devices probe
> even if their suppliers don't have any drivers.
>
> Signed-off-by: Saravana Kannan
> ---
> drivers/base/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
As mentioned here:
https://lore.kernel.org/lkml/20220622062027.994614-1-peng@oss.nxp.com/
This patch has the effect that console UART devices which have "dmas"
properties specified in the device tree get deferred for 10 to 20
seconds. This happens on i.MX and likely on other SoCs as well. On i.MX
the dma channel is only requested at UART startup time and not at probe
time. dma is not used for the console. Nevertheless with this driver probe
defers until the dma engine driver is available.
It shouldn't go in as-is.
Sascha
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 61fdfe99b348..977b379a495b 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1613,7 +1613,7 @@ static int __init fw_devlink_setup(char *arg)
> }
> early_param("fw_devlink", fw_devlink_setup);
>
> -static bool fw_devlink_strict;
> +static bool fw_devlink_strict = true;
> static int __init fw_devlink_strict_setup(char *arg)
> {
> return strtobool(arg, &fw_devlink_strict);
> --
> 2.36.1.255.ge46751e96f-goog
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 7/9] driver core: Set fw_devlink.strict=1 by default
On Wed, Jun 22, 2022 at 12:52:02PM +0200, Andy Shevchenko wrote: > On Wed, Jun 22, 2022 at 10:44 AM Linus Walleij > wrote: > > On Wed, Jun 22, 2022 at 9:48 AM Sascha Hauer wrote: > > ... > > > > This patch has the effect that console UART devices which have "dmas" > > > properties specified in the device tree get deferred for 10 to 20 > > > seconds. This happens on i.MX and likely on other SoCs as well. On i.MX > > > the dma channel is only requested at UART startup time and not at probe > > > time. dma is not used for the console. Nevertheless with this driver probe > > > defers until the dma engine driver is available. > > > > > > It shouldn't go in as-is. > > > > This affects all machines with the PL011 UART and DMAs specified as > > well. > > > > It would be best if the console subsystem could be treated special and > > not require DMA devlink to be satisfied before probing. > > In 8250 we force disable DMA and PM on kernel consoles, because it's > so-o PITA and has a lot of corner cases we may never chase down. On i.MX this is done as well, but it doesn't help here. The driver is not even probed when the device node contains a "dmas" property. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 1/2] driver core: fw_devlink: Allow firmware to mark devices as best effort
On Wed, Jun 22, 2022 at 02:59:10PM -0700, Saravana Kannan wrote:
> When firmware sets the FWNODE_FLAG_BEST_EFFORT flag for a fwnode,
> fw_devlink will do a best effort ordering for that device where it'll
> only enforce the probe/suspend/resume ordering of that device with
> suppliers that have drivers. The driver of that device can then decide
> if it wants to defer probe or probe without the suppliers.
>
> This will be useful for avoid probe delays of the console device that
> were caused by commit 71066545b48e ("driver core: Set
> fw_devlink.strict=1 by default").
>
> Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> Reported-by: Sascha Hauer
> Reported-by: Peng Fan
> Signed-off-by: Saravana Kannan
> ---
> drivers/base/core.c| 3 ++-
> include/linux/fwnode.h | 4
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 839f64485a55..61edd18b7bf3 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -968,7 +968,8 @@ static void device_links_missing_supplier(struct device
> *dev)
>
> static bool dev_is_best_effort(struct device *dev)
> {
> - return fw_devlink_best_effort && dev->can_match;
> + return (fw_devlink_best_effort && dev->can_match) ||
> + dev->fwnode->flags & FWNODE_FLAG_BEST_EFFORT;
Check for dev->fwnode first. I am running in a NULL pointer exception
here for a device that doesn't have a fwnode.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1
On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> enabled iommus and dmas dependency enforcement by default. On some
> systems, this caused the console device's probe to get delayed until the
> deferred_probe_timeout expires.
>
> We need consoles to work as soon as possible, so mark the console device
> node with FWNODE_FLAG_BEST_EFFORT so that fw_delink knows not to delay
> the probe of the console device for suppliers without drivers. The
> driver can then make the decision on where it can probe without those
> suppliers or defer its probe.
>
> Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> Reported-by: Sascha Hauer
> Reported-by: Peng Fan
> Signed-off-by: Saravana Kannan
> Tested-by: Peng Fan
> ---
> drivers/of/base.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/of/base.c b/drivers/of/base.c
> index d4f98c8469ed..a19cd0c73644 100644
> --- a/drivers/of/base.c
> +++ b/drivers/of/base.c
> @@ -1919,6 +1919,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
> align))
> of_property_read_string(of_aliases, "stdout", &name);
> if (name)
> of_stdout = of_find_node_opts_by_path(name,
> &of_stdout_options);
> + if (of_stdout)
> + of_stdout->fwnode.flags |= FWNODE_FLAG_BEST_EFFORT;
The device given in the stdout-path property doesn't necessarily have to
be consistent with the console= parameter. The former is usually
statically set in the device trees contained in the kernel while the
latter is dynamically set by the bootloader. So if you change the
console uart in the bootloader then you'll still run into this trap.
It's problematic to consult only the device tree for dependencies. I
found several examples of drivers in the tree for which dma support
is optional. They use it if they can, but continue without it when
not available. "hwlock" is another property which consider several
drivers as optional. Also consider SoCs in early upstreaming phases
when the device tree is merged with "dmas" or "hwlock" properties,
but the corresponding drivers are not yet upstreamed. It's not nice
to defer probing of all these devices for a long time.
I wonder if it wouldn't be a better approach to just probe all devices
and record the device(node) they are waiting on. Then you know that you
don't need to probe them again until the device they are waiting for
is available.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 2/2] of: base: Avoid console probe delay when fw_devlink.strict=1
On Thu, Jun 23, 2022 at 10:26:46AM -0700, Saravana Kannan wrote:
> On Thu, Jun 23, 2022 at 3:05 AM sascha hauer wrote:
> >
> > On Thu, Jun 23, 2022 at 01:03:43AM -0700, Saravana Kannan wrote:
> > > Commit 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > > enabled iommus and dmas dependency enforcement by default. On some
> > > systems, this caused the console device's probe to get delayed until the
> > > deferred_probe_timeout expires.
> > >
> > > We need consoles to work as soon as possible, so mark the console device
> > > node with FWNODE_FLAG_BEST_EFFORT so that fw_delink knows not to delay
> > > the probe of the console device for suppliers without drivers. The
> > > driver can then make the decision on where it can probe without those
> > > suppliers or defer its probe.
> > >
> > > Fixes: 71066545b48e ("driver core: Set fw_devlink.strict=1 by default")
> > > Reported-by: Sascha Hauer
> > > Reported-by: Peng Fan
> > > Signed-off-by: Saravana Kannan
> > > Tested-by: Peng Fan
> > > ---
> > > drivers/of/base.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/drivers/of/base.c b/drivers/of/base.c
> > > index d4f98c8469ed..a19cd0c73644 100644
> > > --- a/drivers/of/base.c
> > > +++ b/drivers/of/base.c
> > > @@ -1919,6 +1919,8 @@ void of_alias_scan(void * (*dt_alloc)(u64 size, u64
> > > align))
> > > of_property_read_string(of_aliases, "stdout",
> > > &name);
> > > if (name)
> > > of_stdout = of_find_node_opts_by_path(name,
> > > &of_stdout_options);
> > > + if (of_stdout)
> > > + of_stdout->fwnode.flags |= FWNODE_FLAG_BEST_EFFORT;
> >
> > The device given in the stdout-path property doesn't necessarily have to
> > be consistent with the console= parameter. The former is usually
> > statically set in the device trees contained in the kernel while the
> > latter is dynamically set by the bootloader. So if you change the
> > console uart in the bootloader then you'll still run into this trap.
> >
> > It's problematic to consult only the device tree for dependencies. I
> > found several examples of drivers in the tree for which dma support
> > is optional. They use it if they can, but continue without it when
> > not available. "hwlock" is another property which consider several
> > drivers as optional. Also consider SoCs in early upstreaming phases
> > when the device tree is merged with "dmas" or "hwlock" properties,
> > but the corresponding drivers are not yet upstreamed. It's not nice
> > to defer probing of all these devices for a long time.
> >
> > I wonder if it wouldn't be a better approach to just probe all devices
> > and record the device(node) they are waiting on. Then you know that you
> > don't need to probe them again until the device they are waiting for
> > is available.
>
> That actually breaks things in a worse sense. There are cases where
> the consumer driver is built in and the optional supplier driver is
> loaded at boot. Without fw_devlink and the deferred probe timeout, we
> end up probing the consumer with limited functionality. With the
> current setup, sure we delay some probes a bit but at least everything
> works with the right functionality. And you can reduce or remove the
> delay if you want to optimize it.
We have optional and mandatory resources. In this situation a driver has
to decide what to do. Either it continues with limited resources or it
defers probing. Some drivers try to allocate the optional resources at
open time so that they are able to use them once they are available. We
could even think of an asynchronous callback into a driver when a
resource becomes available. Whether we put this decision what is
optional or not into the driver or in the framework doesn't make a
difference to the problem, it is still the same: When a resource is not
yet available we have no idea if and when it becomes available, if it's
worth waiting for it or not.
The difference is that with my proposal (which isn't actually mine but
from my collegue Lucas) a driver can decide very fine grained how it
wants to deal with the situation. With fw_devlink we try to put this
intelligence into the framework and it seems there are quite some quirks
necessary to get that running for everyone.
Anyway, we have fw_devlink now and actually I think the dependency graph
that we have with
Re: CAAM: kernel BUG at drivers/crypto/caam/jr.c:230! (and dma-coherent query)
On Wed, Mar 03, 2021 at 12:26:32PM +0200, Horia Geantă wrote: > Adding some people in the loop, maybe they could help in understanding > why lack of "dma-coherent" property for a HW-coherent device could lead to > unexpected / strange side effects. > > On 3/1/2021 5:22 PM, Sascha Hauer wrote: > > Hi All, > > > > I am on a Layerscape LS1046a using Linux-5.11. The CAAM driver sometimes > > crashes during the run-time self tests with: > > > >> kernel BUG at drivers/crypto/caam/jr.c:247! > >> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP > >> Modules linked in: > >> CPU: 0 PID: 0 Comm: swapper/0 Not tainted > >> 5.11.0-20210225-3-00039-g434215968816-dirty #12 > >> Hardware name: TQ TQMLS1046A SoM on Arkona AT1130 (C300) board (DT) > >> pstate: 6005 (nZCv daif -PAN -UAO -TCO BTYPE=--) > >> pc : caam_jr_dequeue+0x98/0x57c > >> lr : caam_jr_dequeue+0x98/0x57c > >> sp : 800010003d50 > >> x29: 800010003d50 x28: 8000118d4000 > >> x27: 8000118d4328 x26: 01f0 > >> x25: 0008022be480 x24: 0008022c6410 > >> x23: 01f1 x22: 8000118d4329 > >> x21: 4d80 x20: 01f1 > >> x19: 0001 x18: 0020 > >> x17: x16: 0015 > >> x15: 800011690230 x14: 2e2e2e2e2e2e2e2e > >> x13: 2e2e2e2e2e2e2020 x12: 3030303030303030 > >> x11: 800011700a38 x10: f000 > >> x9 : 8000100ada30 x8 : 8000116a8a38 > >> x7 : 0001 x6 : > >> x5 : x4 : > >> x3 : x2 : > >> x1 : x0 : 1800 > >> Call trace: > >> caam_jr_dequeue+0x98/0x57c > >> tasklet_action_common.constprop.0+0x164/0x18c > >> tasklet_action+0x44/0x54 > >> __do_softirq+0x160/0x454 > >> __irq_exit_rcu+0x164/0x16c > >> irq_exit+0x1c/0x30 > >> __handle_domain_irq+0xc0/0x13c > >> gic_handle_irq+0x5c/0xf0 > >> el1_irq+0xb4/0x180 > >> arch_cpu_idle+0x18/0x30 > >> default_idle_call+0x3c/0x1c0 > >> do_idle+0x23c/0x274 > >> cpu_startup_entry+0x34/0x70 > >> rest_init+0xdc/0xec > >> arch_call_rest_init+0x1c/0x28 > >> start_kernel+0x4ac/0x4e4 > >> Code: 91392021 912c2000 d377d8c6 97f24d96 (d421) > > > > The driver iterates over the descriptors in the output ring and matches them > > with the ones it has previously queued. If it doesn't find a matching > > descriptor it complains with the BUG_ON() seen above. What I see sometimes > > is > > that the address in the output ring is 0x0, the job status in this case is > > 0x4006 (meaning DECO Invalid KEY command). It seems that the CAAM > > doesn't > > write the descriptor address to the output ring at least in some error > > cases. > > When we don't have the descriptor address of the failed descriptor we have > > no > > way to find it in the list of queued descriptors, thus we also can't find > > the > > callback for that descriptor. This looks very unfortunate, anyone else seen > > this or has an idea what to do about it? > > > > I haven't investigated yet which job actually fails and why. Of course that > > would > > be my ultimate goal to find that out. > > > This looks very similar to an earlier report from Greg. > He confirmed that adding "dma-coherent" property to the "crypto" DT node > fixes the issue: > https://lore.kernel.org/linux-crypto/74f664f5-5433-d322-4789-3c78bdb81...@kernel.org > Patch rebased on v5.11 is at the bottom. Does it work for you too? Indeed this seems to solve it for me as well, you can add my Tested-by: Sascha Hauer However, there seem to be two problems: First that "DECO Invalid KEY command" actually occurs and second that the deqeueue code currently can't handle a NULL pointer in the output ring. Do you think that the occurence of a NULL pointer is also a coherency issue? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
