Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
26.04.2021 10:14, Thierry Reding пишет: > On Sat, Apr 24, 2021 at 11:27:10PM +0300, Dmitry Osipenko wrote: >> 23.04.2021 18:23, Dmitry Osipenko пишет: >>> 23.04.2021 18:01, Guillaume Tucker пишет: On 02/04/2021 15:40, Dmitry Osipenko wrote: > 01.04.2021 11:55, Nicolin Chen пишет: >> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: >>> The previous commit fixes problem where display client was attaching too >>> early to IOMMU during kernel boot in a multi-platform kernel >>> configuration >>> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to >>> defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, >>> revert it. >> >> Sorry for the late reply. I have been busy with downstream tasks. >> >> I will give them a try by the end of the week. Yet, probably it'd >> be better to include Guillaume also as he has the Nyan platform. >> > > Indeed, thanks. Although, I'm pretty sure that it's the same issue which > I reproduced on Nexus 7. > > Guillaume, could you please give a test to these patches on Nyan Big? > There should be no EMEM errors in the kernel log with this patches. > > https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 So sorry for the very late reply. I have tried the patches but hit some issues on linux-next, it's not reaching a login prompt with next-20210422. So I then tried with next-20210419 which does boot but shows the IOMMU error: <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping https://lava.collabora.co.uk/scheduler/job/3570052#L1120 The branch I'm using with the patches applied can be found here: https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ Hope this helps, let me know if you need anything else to be tested. >>> >>> >>> Hello Guillaume, >>> >>> The current linux-next doesn't boot on all ARM (AFAIK), the older >>> next-20210413 works. The above message should be unrelated to the boot >>> problem. It should be okay to ignore that message as it should be >>> harmless in yours case. >>> >> >> Although, the 20210419 should be good. >> >> Thierry, do you know what those SOR and Nouveau issues are about? > > There's a use-after-free (though it's really a use-before-init) issue in > linux-next at the moment, but a fix has been suggested. The fix for this > along with an additional leak plug is here: > > http://patchwork.ozlabs.org/project/linux-tegra/list/?series=240569 Nice, thank you. Maybe Guillaume could give it a test. > I'm not aware of any Nouveau issues. What version and platform are those > happening on? Are there any logs? I can't seem to find them in this > thread. This all is on Nyan Big using linux-next-20210419. There is a link to the full log above. I see this Nouveau failure: <6>[ 19.323113] nouveau 5700.gpu: Adding to iommu group 2 <6>[ 19.323615] nouveau 5700.gpu: NVIDIA GK20A (0ea000a1) <6>[ 19.323668] nouveau 5700.gpu: imem: using IOMMU <3>[ 19.323795] nouveau 5700.gpu: gr ctor failed: -2 <4>[ 19.323983] nouveau: probe of 5700.gpu failed with error -2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
On Sat, Apr 24, 2021 at 11:27:10PM +0300, Dmitry Osipenko wrote: > 23.04.2021 18:23, Dmitry Osipenko пишет: > > 23.04.2021 18:01, Guillaume Tucker пишет: > >> On 02/04/2021 15:40, Dmitry Osipenko wrote: > >>> 01.04.2021 11:55, Nicolin Chen пишет: > On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: > > The previous commit fixes problem where display client was attaching too > > early to IOMMU during kernel boot in a multi-platform kernel > > configuration > > which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to > > defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, > > revert it. > > Sorry for the late reply. I have been busy with downstream tasks. > > I will give them a try by the end of the week. Yet, probably it'd > be better to include Guillaume also as he has the Nyan platform. > > >>> > >>> Indeed, thanks. Although, I'm pretty sure that it's the same issue which > >>> I reproduced on Nexus 7. > >>> > >>> Guillaume, could you please give a test to these patches on Nyan Big? > >>> There should be no EMEM errors in the kernel log with this patches. > >>> > >>> https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 > >> > >> So sorry for the very late reply. I have tried the patches but > >> hit some issues on linux-next, it's not reaching a login prompt > >> with next-20210422. So I then tried with next-20210419 which > >> does boot but shows the IOMMU error: > >> > >> <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 > >> <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping > >> > >> https://lava.collabora.co.uk/scheduler/job/3570052#L1120 > >> > >> The branch I'm using with the patches applied can be found here: > >> > >> > >> https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ > >> > >> Hope this helps, let me know if you need anything else to be > >> tested. > > > > > > Hello Guillaume, > > > > The current linux-next doesn't boot on all ARM (AFAIK), the older > > next-20210413 works. The above message should be unrelated to the boot > > problem. It should be okay to ignore that message as it should be > > harmless in yours case. > > > > Although, the 20210419 should be good. > > Thierry, do you know what those SOR and Nouveau issues are about? There's a use-after-free (though it's really a use-before-init) issue in linux-next at the moment, but a fix has been suggested. The fix for this along with an additional leak plug is here: http://patchwork.ozlabs.org/project/linux-tegra/list/?series=240569 I'm not aware of any Nouveau issues. What version and platform are those happening on? Are there any logs? I can't seem to find them in this thread. Thierry signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
24.04.2021 23:27, Dmitry Osipenko пишет: > 23.04.2021 18:23, Dmitry Osipenko пишет: >> 23.04.2021 18:01, Guillaume Tucker пишет: >>> On 02/04/2021 15:40, Dmitry Osipenko wrote: 01.04.2021 11:55, Nicolin Chen пишет: > On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: >> The previous commit fixes problem where display client was attaching too >> early to IOMMU during kernel boot in a multi-platform kernel >> configuration >> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to >> defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, >> revert it. > > Sorry for the late reply. I have been busy with downstream tasks. > > I will give them a try by the end of the week. Yet, probably it'd > be better to include Guillaume also as he has the Nyan platform. > Indeed, thanks. Although, I'm pretty sure that it's the same issue which I reproduced on Nexus 7. Guillaume, could you please give a test to these patches on Nyan Big? There should be no EMEM errors in the kernel log with this patches. https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 >>> >>> So sorry for the very late reply. I have tried the patches but >>> hit some issues on linux-next, it's not reaching a login prompt >>> with next-20210422. So I then tried with next-20210419 which >>> does boot but shows the IOMMU error: >>> >>> <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 >>> <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping >>> >>> https://lava.collabora.co.uk/scheduler/job/3570052#L1120 >>> >>> The branch I'm using with the patches applied can be found here: >>> >>> >>> https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ >>> >>> Hope this helps, let me know if you need anything else to be >>> tested. >> >> >> Hello Guillaume, >> >> The current linux-next doesn't boot on all ARM (AFAIK), the older >> next-20210413 works. The above message should be unrelated to the boot >> problem. It should be okay to ignore that message as it should be >> harmless in yours case. >> > > Although, the 20210419 should be good. > > Thierry, do you know what those SOR and Nouveau issues are about? > I don't see DRM driver being loaded at all and no errors related to it in the log. This means that likely some of the DRM sub-drivers is stuck in deferred probe. Guillaume, could you please show contents of /sys/kernel/debug/devices_deferred ? These messages also don't look good: tegra-xusb-padctl 7009f000.padctl: failed to setup XUSB ports: -22 tegra-xusb-padctl: probe of 7009f000.padctl failed with error -22 I don't have T124 and all these problems should be specific to the T124 platform. Somebody with a direct access to hardware should look into it. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
23.04.2021 18:23, Dmitry Osipenko пишет: > 23.04.2021 18:01, Guillaume Tucker пишет: >> On 02/04/2021 15:40, Dmitry Osipenko wrote: >>> 01.04.2021 11:55, Nicolin Chen пишет: On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: > The previous commit fixes problem where display client was attaching too > early to IOMMU during kernel boot in a multi-platform kernel configuration > which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to > defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, > revert it. Sorry for the late reply. I have been busy with downstream tasks. I will give them a try by the end of the week. Yet, probably it'd be better to include Guillaume also as he has the Nyan platform. >>> >>> Indeed, thanks. Although, I'm pretty sure that it's the same issue which >>> I reproduced on Nexus 7. >>> >>> Guillaume, could you please give a test to these patches on Nyan Big? >>> There should be no EMEM errors in the kernel log with this patches. >>> >>> https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 >> >> So sorry for the very late reply. I have tried the patches but >> hit some issues on linux-next, it's not reaching a login prompt >> with next-20210422. So I then tried with next-20210419 which >> does boot but shows the IOMMU error: >> >> <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 >> <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping >> >> https://lava.collabora.co.uk/scheduler/job/3570052#L1120 >> >> The branch I'm using with the patches applied can be found here: >> >> >> https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ >> >> Hope this helps, let me know if you need anything else to be >> tested. > > > Hello Guillaume, > > The current linux-next doesn't boot on all ARM (AFAIK), the older > next-20210413 works. The above message should be unrelated to the boot > problem. It should be okay to ignore that message as it should be > harmless in yours case. > Although, the 20210419 should be good. Thierry, do you know what those SOR and Nouveau issues are about? ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
23.04.2021 18:01, Guillaume Tucker пишет: > On 02/04/2021 15:40, Dmitry Osipenko wrote: >> 01.04.2021 11:55, Nicolin Chen пишет: >>> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: The previous commit fixes problem where display client was attaching too early to IOMMU during kernel boot in a multi-platform kernel configuration which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, revert it. >>> >>> Sorry for the late reply. I have been busy with downstream tasks. >>> >>> I will give them a try by the end of the week. Yet, probably it'd >>> be better to include Guillaume also as he has the Nyan platform. >>> >> >> Indeed, thanks. Although, I'm pretty sure that it's the same issue which >> I reproduced on Nexus 7. >> >> Guillaume, could you please give a test to these patches on Nyan Big? >> There should be no EMEM errors in the kernel log with this patches. >> >> https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 > > So sorry for the very late reply. I have tried the patches but > hit some issues on linux-next, it's not reaching a login prompt > with next-20210422. So I then tried with next-20210419 which > does boot but shows the IOMMU error: > > <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 > <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping > > https://lava.collabora.co.uk/scheduler/job/3570052#L1120 > > The branch I'm using with the patches applied can be found here: > > > https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ > > Hope this helps, let me know if you need anything else to be > tested. Hello Guillaume, The current linux-next doesn't boot on all ARM (AFAIK), the older next-20210413 works. The above message should be unrelated to the boot problem. It should be okay to ignore that message as it should be harmless in yours case. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
On 02/04/2021 15:40, Dmitry Osipenko wrote: > 01.04.2021 11:55, Nicolin Chen пишет: >> On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: >>> The previous commit fixes problem where display client was attaching too >>> early to IOMMU during kernel boot in a multi-platform kernel configuration >>> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to >>> defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, >>> revert it. >> >> Sorry for the late reply. I have been busy with downstream tasks. >> >> I will give them a try by the end of the week. Yet, probably it'd >> be better to include Guillaume also as he has the Nyan platform. >> > > Indeed, thanks. Although, I'm pretty sure that it's the same issue which > I reproduced on Nexus 7. > > Guillaume, could you please give a test to these patches on Nyan Big? > There should be no EMEM errors in the kernel log with this patches. > > https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 So sorry for the very late reply. I have tried the patches but hit some issues on linux-next, it's not reaching a login prompt with next-20210422. So I then tried with next-20210419 which does boot but shows the IOMMU error: <6>[2.995341] tegra-dc 5420.dc: Adding to iommu group 1 <4>[3.001070] Failed to attached device 5420.dc to IOMMU_mapping https://lava.collabora.co.uk/scheduler/job/3570052#L1120 The branch I'm using with the patches applied can be found here: https://gitlab.collabora.com/gtucker/linux/-/commits/next-20210419-nyan-big-drm-read/ Hope this helps, let me know if you need anything else to be tested. Best wishes, Guillaume ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
01.04.2021 11:55, Nicolin Chen пишет: > On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: >> The previous commit fixes problem where display client was attaching too >> early to IOMMU during kernel boot in a multi-platform kernel configuration >> which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to >> defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, >> revert it. > > Sorry for the late reply. I have been busy with downstream tasks. > > I will give them a try by the end of the week. Yet, probably it'd > be better to include Guillaume also as he has the Nyan platform. > Indeed, thanks. Although, I'm pretty sure that it's the same issue which I reproduced on Nexus 7. Guillaume, could you please give a test to these patches on Nyan Big? There should be no EMEM errors in the kernel log with this patches. https://patchwork.ozlabs.org/project/linux-tegra/list/?series=236215 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
On Mon, Mar 29, 2021 at 02:32:56AM +0300, Dmitry Osipenko wrote: > The previous commit fixes problem where display client was attaching too > early to IOMMU during kernel boot in a multi-platform kernel configuration > which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to > defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore, > revert it. Sorry for the late reply. I have been busy with downstream tasks. I will give them a try by the end of the week. Yet, probably it'd be better to include Guillaume also as he has the Nyan platform. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
The previous commit fixes problem where display client was attaching too
early to IOMMU during kernel boot in a multi-platform kernel configuration
which enables CONFIG_ARM_DMA_USE_IOMMU=y. The workaround that helped to
defer the IOMMU attachment for Nyan Big Chromebook isn't needed anymore,
revert it.
Signed-off-by: Dmitry Osipenko
---
drivers/iommu/tegra-smmu.c | 71 +-
1 file changed, 1 insertion(+), 70 deletions(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index af1e4b5adb27..572a4544ae88 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -869,69 +869,10 @@ static phys_addr_t tegra_smmu_iova_to_phys(struct
iommu_domain *domain,
return SMMU_PFN_PHYS(pfn) + SMMU_OFFSET_IN_PAGE(iova);
}
-static struct tegra_smmu *tegra_smmu_find(struct device_node *np)
-{
- struct platform_device *pdev;
- struct tegra_mc *mc;
-
- pdev = of_find_device_by_node(np);
- if (!pdev)
- return NULL;
-
- mc = platform_get_drvdata(pdev);
- if (!mc)
- return NULL;
-
- return mc->smmu;
-}
-
-static int tegra_smmu_configure(struct tegra_smmu *smmu, struct device *dev,
- struct of_phandle_args *args)
-{
- const struct iommu_ops *ops = smmu->iommu.ops;
- int err;
-
- err = iommu_fwspec_init(dev, >of_node->fwnode, ops);
- if (err < 0) {
- dev_err(dev, "failed to initialize fwspec: %d\n", err);
- return err;
- }
-
- err = ops->of_xlate(dev, args);
- if (err < 0) {
- dev_err(dev, "failed to parse SW group ID: %d\n", err);
- iommu_fwspec_free(dev);
- return err;
- }
-
- return 0;
-}
-
static struct iommu_device *tegra_smmu_probe_device(struct device *dev)
{
- struct device_node *np = dev->of_node;
- struct tegra_smmu *smmu = NULL;
- struct of_phandle_args args;
- unsigned int index = 0;
- int err;
-
- while (of_parse_phandle_with_args(np, "iommus", "#iommu-cells", index,
- ) == 0) {
- smmu = tegra_smmu_find(args.np);
- if (smmu) {
- err = tegra_smmu_configure(smmu, dev, );
-
- if (err < 0) {
- of_node_put(args.np);
- return ERR_PTR(err);
- }
- }
-
- of_node_put(args.np);
- index++;
- }
+ struct tegra_smmu *smmu = dev_iommu_priv_get(dev);
- smmu = dev_iommu_priv_get(dev);
if (!smmu)
return ERR_PTR(-ENODEV);
@@ -1158,16 +1099,6 @@ struct tegra_smmu *tegra_smmu_probe(struct device *dev,
if (!smmu)
return ERR_PTR(-ENOMEM);
- /*
-* This is a bit of a hack. Ideally we'd want to simply return this
-* value. However the IOMMU registration process will attempt to add
-* all devices to the IOMMU when bus_set_iommu() is called. In order
-* not to rely on global variables to track the IOMMU instance, we
-* set it here so that it can be looked up from the .probe_device()
-* callback via the IOMMU device's .drvdata field.
-*/
- mc->smmu = smmu;
-
size = BITS_TO_LONGS(soc->num_asids) * sizeof(long);
smmu->asids = devm_kzalloc(dev, size, GFP_KERNEL);
--
2.30.2
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
