[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <207e6b6a297d5ce1bdcac204e297389b@codeaurora.org>
Date: Tue, 28 Jul 2020 10:10:11 +0530
From: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Andy Gross <agross@...nel.org>, Stephen Boyd <swboyd@...omium.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
Mathieu Poirier <mathieu.poirier@...aro.org>,
Suzuki K Poulose <suzuki.poulose@....com>,
mike.leach@...aro.org, Jonathan Marek <jonathan@...ek.ca>
Subject: Re: [PATCH 2/4] arm64: dts: qcom: sc7180: Add iommus property to ETR
On 2020-07-28 02:28, Bjorn Andersson wrote:
> On Tue 23 Jun 23:56 PDT 2020, Sai Prakash Ranjan wrote:
>
>> Hi Bjorn,
>>
>> On 2020-06-21 13:39, Sai Prakash Ranjan wrote:
>> > Hi Bjorn,
>> >
>> > On 2020-06-21 12:52, Bjorn Andersson wrote:
>> > > On Tue 09 Jun 06:30 PDT 2020, Sai Prakash Ranjan wrote:
>> > >
>> > > > Define iommus property for Coresight ETR component in
>> > > > SC7180 SoC with the SID and mask to enable SMMU
>> > > > translation for this master.
>> > > >
>> > >
>> > > We don't have &apps_smmu in linux-next, as we've yet to figure out how
>> > > to disable the boot splash or support the stream mapping handover.
>> > >
>> > > So I'm not able to apply this.
>> > >
>> >
>> > This is for SC7180 which has apps_smmu not SM8150.
>> >
>>
>> Please let me know if this needs further explanation.
>>
>
> I must have commented on the wrong patch, sorry about that. The SM8150
> patch in this series does not compile due to the lack of &apps_smmu.
>
> I've picked the other 3 patches.
>
Thanks Bjorn, I can resend SM8150 coresight change when SMMU support
lands for it
since coresight ETR won't work without it on android bootloaders.
As for the other 3 patches, Patch 1 and Patch 2 will apply cleanly to
the right coresight
nodes but due to the missing unique context in Patch 3, it could be
applied to some other node.
We had to upload this change 3 times in chromium tree to get it applied
to the right replicator node :)
and this property in Patch 3 is important to fix a hard lockup. I'm not
sure why this patch is missing
the proper context :/
I couldn't find the changes yet in qcom/for-next or other branches to
see if it is
applied to right replicator node. In case you haven't applied it yet,
Patch 3 change
should be applied to "replicator@...6000" node.
Thanks,
Sai
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member
of Code Aurora Forum, hosted by The Linux Foundation
Powered by blists - more mailing lists