devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
To: Jonathan Marek <jonathan@marek.ca>
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 17:28:14 +0530	[thread overview]
Message-ID: <d87d527e38ce256ec32fd63b777c98e6@codeaurora.org> (raw)
In-Reply-To: <8f9a5750-7909-4be7-6780-198d8c242af3@marek.ca>

On 2020-05-25 17:23, Jonathan Marek wrote:
> On 5/25/20 7:40 AM, Sai Prakash Ranjan wrote:
>> On 2020-05-25 16:57, Jonathan Marek wrote:
>>> 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).
>>> 
>> 
>> Your commit description says "adding the iommus field for UFS is 
>> required
>> because initializing the iommu removes the bypass mapping that created 
>> by the
>> bootloader". So here it would mean like iommus property for UFS is not 
>> for
>> enabling address translation by SMMU for UFS but to avoid removing 
>> mappings
>> created by the bootloader which is not exactly what iommus property is 
>> for.
>> 
> 
> I guess the commit message is ambiguous, that's not what I meant. Is
> "Now that the kernel initializes the iommu, the bypass mappings set by
> the bootloader are cleared. Adding the iommus property is required so
> that new mappings are created for UFS." better?
> 

Yes looks good.

>>>>> 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.
>>> 
>> 
>> Ok since you are very sure about this, I will try with your patches on
>> SM8150 MTP tomorrow since I do not have access to one now.
>> Also just to make sure, please remove all the extra SMMU patches you 
>> have
>> in your tree which are not yet merged or from downstream kernel.
>> 
> 
> FYI, I have a branch [1] integrating patches for upstream. All the
> patches up to 34fff8a519cc075933 ("arm64: dts: qcom: add sm8250 GPU
> nodes") have been submitted (and the patches after that are
> unnecessary for testing on sm8150).
> 
> [1] https://github.com/flto/linux/commits/sm8x50-upstream
> 

Thanks, I will test this out.

-Sai
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation

  reply	other threads:[~2020-05-25 11:58 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
2020-05-25 11:40               ` Sai Prakash Ranjan
2020-05-25 11:53                 ` Jonathan Marek
2020-05-25 11:58                   ` Sai Prakash Ranjan [this message]
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=d87d527e38ce256ec32fd63b777c98e6@codeaurora.org \
    --to=saiprakash.ranjan@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathan@marek.ca \
    --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 \
    /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;
as well as URLs for NNTP newsgroup(s).