From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: Diana Madalina Craciun <diana.craciun@nxp.com>,
iommu@lists.linux-foundation.org,
Robin Murphy <robin.murphy@arm.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>
Subject: Re: [PATCH] iommu: silence iommu group prints
Date: Wed, 4 Mar 2020 09:51:12 +0000 [thread overview]
Message-ID: <20200304095112.GY25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <78f175be-0701-b6cd-8feb-1343f9982d4c@nxp.com>
On Wed, Mar 04, 2020 at 11:42:16AM +0200, Laurentiu Tudor wrote:
> On 04.03.2020 11:33, Russell King - ARM Linux admin wrote:
> > On Wed, Mar 04, 2020 at 10:56:06AM +0200, Laurentiu Tudor wrote:
> > >
> > > On 04.03.2020 00:17, Russell King - ARM Linux admin wrote:
> > > > On Tue, Mar 03, 2020 at 05:55:05PM +0200, Laurentiu Tudor wrote:
> > > > > From c98dc05cdd45ae923654f2427985bd28bcde4bb2 Mon Sep 17 00:00:00 2001
> > > > > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > > > Date: Thu, 13 Feb 2020 11:59:12 +0200
> > > > > Subject: [PATCH 1/4] bus: fsl-mc: add custom .dma_configure implementation
> > > > > Content-Type: text/plain; charset="us-ascii"
> > > > >
> > > > > The devices on this bus are not discovered by way of device tree
> > > > > but by queries to the firmware. It makes little sense to trick the
> > > > > generic of layer into thinking that these devices are of related so
> > > > > that we can get our dma configuration. Instead of doing that, add
> > > > > our custom dma configuration implementation.
> > > >
> > > > Firstly, applying this to v5.5 results in a build failure, due to a
> > > > missing linux/iommu.h include.
> > > >
> > > > Secondly, this on its own appears to make the DPAA2 network interfaces
> > > > completely disappear. Looking in /sys/bus/fsl-mc/drivers/*, none of
> > > > the DPAA2 drivers are bound to anything, and looking in
> > > > /sys/bus/fsl-mc/devices/, there is:
> > > >
> > > > lrwxrwxrwx 1 root root 0 Mar 3 22:06 dprc.1 -> ../../../devices/platform/soc/80c000000.fsl-mc/dprc.1
> > > >
> > > > This is booting with u-boot, so using DT rather than ACPI.
> > > >
> > > > > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > > > ---
> > > > > drivers/bus/fsl-mc/fsl-mc-bus.c | 42 ++++++++++++++++++++++++++++++++-
> > > > > 1 file changed, 41 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > index 36eb25f82c8e..3df015eedae4 100644
> > > > > --- a/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > +++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
> > > > > @@ -132,11 +132,51 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
> > > > > static int fsl_mc_dma_configure(struct device *dev)
> > > > > {
> > > > > struct device *dma_dev = dev;
> > > > > + struct iommu_fwspec *fwspec;
> > > > > + const struct iommu_ops *iommu_ops;
> > > > > + struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
> > > > > + int ret;
> > > > > + u32 icid;
> > > > > +
> > > > > + /* Skip DMA setup for devices that are not DMA masters */
> > > > > + if (dev->type == &fsl_mc_bus_dpmcp_type ||
> > > > > + dev->type == &fsl_mc_bus_dpbp_type ||
> > > > > + dev->type == &fsl_mc_bus_dpcon_type ||
> > > > > + dev->type == &fsl_mc_bus_dpio_type)
> > > > > + return 0;
> > > > > while (dev_is_fsl_mc(dma_dev))
> > > > > dma_dev = dma_dev->parent;
> > > > > - return of_dma_configure(dev, dma_dev->of_node, 0);
> > > > > + fwspec = dev_iommu_fwspec_get(dma_dev);
> > > > > + if (!fwspec)
> > > > > + return -ENODEV;
> > > >
> > > > The problem appears to be here - fwspec is NULL for dprc.1.
> > >
> > > Ok, that's because the iommu config is missing from the DT node that's
> > > exposing the MC firmware. I've attached a fresh set of patches that include
> > > on top the missing config and a workaround that makes MC work over SMMU.
> > > Also added the missing #include, thanks for pointing out.
> > > Let me know how it goes.
> >
> > Shouldn't patch 6 should be first in the series, so that patch 1 does
> > not cause a regression and bisectability damage?
> >
>
> Correct, width one comment: both 5 and 6 should go first. Once iommu-map is
> added in the device tree the workaround for MC with the
> arm-smmu.disable_bypass boot arg will no longer work.
So, wouldn't it be reasonable to arrange the patch series like that?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2020-03-04 9:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-27 11:57 [PATCH] iommu: silence iommu group prints Russell King
2020-02-27 13:44 ` Robin Murphy
2020-02-27 13:48 ` Russell King - ARM Linux admin
2020-02-27 18:19 ` Robin Murphy
2020-02-27 19:00 ` Russell King - ARM Linux admin
2020-02-28 2:16 ` Lu Baolu
2020-02-28 9:33 ` John Garry
2020-02-28 10:06 ` Russell King - ARM Linux admin
2020-02-28 18:32 ` Robin Murphy
2020-03-02 11:48 ` Laurentiu Tudor
2020-03-03 14:18 ` Laurentiu Tudor
2020-03-03 15:49 ` Russell King - ARM Linux admin
2020-03-03 15:55 ` Laurentiu Tudor
2020-03-03 22:17 ` Russell King - ARM Linux admin
2020-03-04 8:56 ` Laurentiu Tudor
2020-03-04 9:33 ` Russell King - ARM Linux admin
2020-03-04 9:42 ` Laurentiu Tudor
2020-03-04 9:51 ` Russell King - ARM Linux admin [this message]
2020-03-04 9:56 ` Laurentiu Tudor
2020-03-04 10:07 ` Russell King - ARM Linux admin
2020-03-04 10:33 ` Laurentiu Tudor
2020-03-04 10:52 ` Russell King - ARM Linux admin
2020-03-04 11:26 ` Laurentiu Tudor
2020-03-02 15:44 ` Joerg Roedel
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=20200304095112.GY25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=diana.craciun@nxp.com \
--cc=ioana.ciornei@nxp.com \
--cc=iommu@lists.linux-foundation.org \
--cc=laurentiu.tudor@nxp.com \
--cc=robin.murphy@arm.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox