From: Jonathan Marek <jonathan@marek.ca>
To: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Cc: linux-arm-msm@vger.kernel.org, Andy Gross <agross@kernel.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH 2/6] arm64: dts: qcom: sm8250: add apps_smmu node
Date: Mon, 25 May 2020 07:27:22 -0400 [thread overview]
Message-ID: <33b34a58-46d2-80ec-1d79-8e02aa5ae026@marek.ca> (raw)
In-Reply-To: <72d771390af9a68759d3f81cb79e46a6@codeaurora.org>
On 5/25/20 7:17 AM, Sai Prakash Ranjan wrote:
> Hi,
>
> On 2020-05-25 16:38, Jonathan Marek wrote:
>> On 5/25/20 6:54 AM, Sai Prakash Ranjan wrote:
>>> On 2020-05-25 15:39, Jonathan Marek wrote:
>>>> Hi,
>>>>
>>>> On 5/25/20 5:42 AM, Sai Prakash Ranjan wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> On 2020-05-24 08:08, Jonathan Marek wrote:
>>>>>> Add the apps_smmu node for sm8250. Note that adding the iommus
>>>>>> field for
>>>>>> UFS is required because initializing the iommu removes the bypass
>>>>>> mapping
>>>>>> that created by the bootloader.
>>>>>>
>>>>>
>>>>> This statement doesn't seem right, you can just say since the
>>>>> bypass is disabled
>>>>> by default now, we need to add this property to enable translation
>>>>> and avoid global faults.
>>>>>
>>>>
>>>> If I use this patch [1] then the UFS iommu property isn't needed. In
>>>> downstream, the identity (bypass?) stream mapping is inherited from
>>>> the bootloader, and UFS is used without any iommu property. Setting
>>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n doesn't make it work on its own
>>>> (without the UFS iommu property), so there's more to it than just
>>>> "bypass is disabled by default now".
>>>>
>>>> https://patchwork.kernel.org/patch/11310757/
>>>>
>>>
>>> "iommus" property is not about inheriting stream mapping from
>>> bootloader,
>>> it is used to enable SMMU address translation for the corresponding
>>> master when specified. So when you have disabled bypass, i.e.,
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y or via cmdline
>>> "arm-smmu.disable_bypass=1"
>>> and iommus property with SID and mask is not specified, then it will
>>> result
>>> in SMMU global faults.
>>>
>>> Downstream has bypass
>>> enabled(ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n),so you
>>> won't see any global faults if you do not have iommus property.
>>>
>>> Patch in your link is for display because of the usecase for splash
>>> screen
>>> on android and some other devices where the bootloader will configure
>>> SMMU,
>>> it has not yet merged and not likely to get merged in the current state.
>>>
>>> So yes "there is *not* much more to it than bypass is disabled by
>>> default now"
>>> and you have to specify "iommus" for the master devices or you should
>>> enable bypass,
>>> i.e., ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or arm-smmu.disable_bypass=n
>>>
>>> Try without the patch in the link and without iommus for UFS and
>>> ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y and you will see.
>>>
>>> -Sai
>>
>> I know that the "iommus" property is not about inheriting stream
>> mapping. Probing the iommu removes the stream mapping created by the
>> bootloader, the iommus property is added so that new mappings are
>> created to replace what was removed.
>>
>> You seem to be under the impression that the SM8150/SM8250 bootloader
>> does not configure SMMU. It does, for both UFS and SDHC, just like it
>> does for display/splash screen on some devices.
>>
>
> It could be that bootloader does configure SMMU for UFS and SDHC, but the
> upstream SMMU driver doesnt allow to inherit stream mapping from the
> bootloader
> yet, so adding iommus property based on the assumption that it is
> inherited seems
> wrong.
>
I never said adding the iommus property is for inheriting stream
mapping. I mentioned inheriting to say UFS works without the iommus
property on downstream (it inherits a identity/bypass mapping).
>> With either value of ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT, it will not
>> work without the iommus property.
>
> I'm pretty sure that if you have ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n and
> without iommus, it should work.
>
It doesn't work, with either ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n or
ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=y.
> -Sai
>
next prev parent reply other threads:[~2020-05-25 11:26 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-24 2:38 [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts Jonathan Marek
2020-05-24 2:38 ` [PATCH 1/6] arm64: dts: qcom: sm8150: add apps_smmu node Jonathan Marek
2020-05-25 9:37 ` Sai Prakash Ranjan
2020-06-05 14:15 ` Sai Prakash Ranjan
2020-05-29 2:52 ` Bjorn Andersson
2020-05-29 3:02 ` Jonathan Marek
2020-05-29 3:15 ` Bjorn Andersson
2020-05-29 3:34 ` Jonathan Marek
2020-05-29 3:42 ` Bjorn Andersson
2020-06-09 19:52 ` Jonathan Marek
2020-06-05 14:03 ` Sai Prakash Ranjan
2020-06-05 14:10 ` Jonathan Marek
2020-06-05 14:13 ` Sai Prakash Ranjan
2020-06-05 14:31 ` Nicolas Dechesne
2020-06-05 14:39 ` Sai Prakash Ranjan
2020-06-05 14:51 ` Nicolas Dechesne
2020-06-05 15:04 ` Sai Prakash Ranjan
2020-05-24 2:38 ` [PATCH 2/6] arm64: dts: qcom: sm8250: " Jonathan Marek
2020-05-25 9:42 ` Sai Prakash Ranjan
2020-05-25 10:09 ` Jonathan Marek
2020-05-25 10:54 ` Sai Prakash Ranjan
2020-05-25 11:08 ` Jonathan Marek
2020-05-25 11:17 ` Sai Prakash Ranjan
2020-05-25 11:27 ` Jonathan Marek [this message]
2020-05-25 11:40 ` Sai Prakash Ranjan
2020-05-25 11:53 ` Jonathan Marek
2020-05-25 11:58 ` Sai Prakash Ranjan
2020-05-29 2:48 ` Bjorn Andersson
2020-05-24 2:38 ` [PATCH 3/6] arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes Jonathan Marek
2020-05-24 2:38 ` [PATCH 4/6] arm64: dts: qcom: sm8250: Add USB and PHY device nodes Jonathan Marek
2020-05-24 2:38 ` [PATCH 5/6] arm64: dts: qcom: add sm8150 hdk dts Jonathan Marek
2020-05-29 3:01 ` Bjorn Andersson
2020-06-09 19:46 ` Jonathan Marek
2020-05-24 2:38 ` [PATCH 6/6] arm64: dts: qcom: add sm8250 " Jonathan Marek
2020-05-29 3:03 ` Bjorn Andersson
2020-06-09 19:42 ` Jonathan Marek
2020-05-29 3:05 ` [PATCH 0/6] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts Bjorn Andersson
2020-05-29 3:15 ` Jonathan Marek
2020-05-29 6:44 ` Bjorn Andersson
2020-06-04 13:52 ` Manivannan Sadhasivam
2020-06-04 14:06 ` Jonathan Marek
2020-06-04 15:58 ` Manivannan Sadhasivam
2020-06-04 16:09 ` Jonathan Marek
2020-06-11 18:05 ` Manivannan Sadhasivam
2020-06-11 18:14 ` Jonathan Marek
2020-06-11 18:22 ` Manivannan Sadhasivam
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=33b34a58-46d2-80ec-1d79-8e02aa5ae026@marek.ca \
--to=jonathan@marek.ca \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=saiprakash.ranjan@codeaurora.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®