All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Guillaume Tucker <guillaume.tucker@collabora.com>,
	Nicolin Chen <nicoleotsuka@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Krishna Reddy <vdumpa@nvidia.com>, Will Deacon <will@kernel.org>,
	iommu@lists.linux-foundation.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
Date: Sat, 24 Apr 2021 23:41:37 +0300	[thread overview]
Message-ID: <4b1eb3d5-6489-6553-ba88-df485323e6e8@gmail.com> (raw)
In-Reply-To: <5ec2be61-a70e-e3b1-9267-414793c32a04@gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Guillaume Tucker <guillaume.tucker@collabora.com>,
	Nicolin Chen <nicoleotsuka@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-tegra@vger.kernel.org, Will Deacon <will@kernel.org>
Subject: Re: [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook
Date: Sat, 24 Apr 2021 23:41:37 +0300	[thread overview]
Message-ID: <4b1eb3d5-6489-6553-ba88-df485323e6e8@gmail.com> (raw)
In-Reply-To: <5ec2be61-a70e-e3b1-9267-414793c32a04@gmail.com>

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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-04-24 20:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-28 23:32 [PATCH v1 1/2] iommu/tegra-smmu: Defer attachment of display clients Dmitry Osipenko
2021-03-28 23:32 ` Dmitry Osipenko
2021-03-28 23:32 ` [PATCH v1 2/2] iommu/tegra-smmu: Revert workaround that was needed for Nyan Big Chromebook Dmitry Osipenko
2021-03-28 23:32   ` Dmitry Osipenko
2021-04-01  8:55   ` Nicolin Chen
2021-04-01  8:55     ` Nicolin Chen
2021-04-02 14:40     ` Dmitry Osipenko
2021-04-02 14:40       ` Dmitry Osipenko
2021-04-23 15:01       ` Guillaume Tucker
2021-04-23 15:01         ` Guillaume Tucker
2021-04-23 15:23         ` Dmitry Osipenko
2021-04-23 15:23           ` Dmitry Osipenko
2021-04-24 20:27           ` Dmitry Osipenko
2021-04-24 20:27             ` Dmitry Osipenko
2021-04-24 20:41             ` Dmitry Osipenko [this message]
2021-04-24 20:41               ` Dmitry Osipenko
2021-04-26  7:14             ` Thierry Reding
2021-04-26  7:14               ` Thierry Reding
2021-04-26  7:39               ` Dmitry Osipenko
2021-04-26  7:39                 ` Dmitry Osipenko
2021-04-08  9:42 ` [PATCH v1 1/2] iommu/tegra-smmu: Defer attachment of display clients Nicolin Chen
2021-04-08  9:42   ` Nicolin Chen
2021-04-08 13:26   ` Thierry Reding
2021-04-08 13:26     ` Thierry Reding
2021-04-08 14:20     ` Dmitry Osipenko
2021-04-08 14:20       ` Dmitry Osipenko
2021-04-08 12:40 ` Thierry Reding
2021-04-08 12:40   ` Thierry Reding
2021-04-08 14:07   ` Dmitry Osipenko
2021-04-08 14:07     ` Dmitry Osipenko
2021-04-09 12:55     ` Dmitry Osipenko
2021-04-09 12:55       ` Dmitry Osipenko

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=4b1eb3d5-6489-6553-ba88-df485323e6e8@gmail.com \
    --to=digetx@gmail.com \
    --cc=guillaume.tucker@collabora.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicoleotsuka@gmail.com \
    --cc=thierry.reding@gmail.com \
    --cc=vdumpa@nvidia.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.