| Message ID | 20210328233256.20494-2-digetx@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [v1,1/2] iommu/tegra-smmu: Defer attachment of display clients | expand |
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.
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
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 54200000.dc: Adding to iommu group 1 <4>[ 3.001070] Failed to attached device 54200000.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
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 54200000.dc: Adding to iommu group 1 > <4>[ 3.001070] Failed to attached device 54200000.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.
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 54200000.dc: Adding to iommu group 1 >> <4>[ 3.001070] Failed to attached device 54200000.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?
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 54200000.dc: Adding to iommu group 1 >>> <4>[ 3.001070] Failed to attached device 54200000.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.
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 54200000.dc: Adding to iommu group 1 > >> <4>[ 3.001070] Failed to attached device 54200000.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
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 54200000.dc: Adding to iommu group 1 >>>> <4>[ 3.001070] Failed to attached device 54200000.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 57000000.gpu: Adding to iommu group 2 <6>[ 19.323615] nouveau 57000000.gpu: NVIDIA GK20A (0ea000a1) <6>[ 19.323668] nouveau 57000000.gpu: imem: using IOMMU <3>[ 19.323795] nouveau 57000000.gpu: gr ctor failed: -2 <4>[ 19.323983] nouveau: probe of 57000000.gpu failed with error -2
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, &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, - &args) == 0) { - smmu = tegra_smmu_find(args.np); - if (smmu) { - err = tegra_smmu_configure(smmu, dev, &args); - - 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);
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 <digetx@gmail.com> --- drivers/iommu/tegra-smmu.c | 71 +------------------------------------- 1 file changed, 1 insertion(+), 70 deletions(-)