[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <010101747c3d2e2e-d8ff7403-32c3-4155-88a5-a05e7985c7f7-000000@us-west-2.amazonses.com>
Date: Fri, 11 Sep 2020 08:16:58 +0000
From: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To: Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
Jordan Crouse <jcrouse@...eaurora.org>,
Rob Clark <robdclark@...omium.org>,
linux-arm-msm@...r.kernel.org, iommu@...ts.linux-foundation.org,
Sibi Sankar <sibis@...eaurora.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/8] iommu/arm-smmu: Support maintaining bootloader
mappings
Hi Bjorn,
On 2020-09-04 21:25, Bjorn Andersson wrote:
> Based on previous attempts and discussions this is the latest attempt
> at
> inheriting stream mappings set up by the bootloader, for e.g. boot
> splash or
> efifb.
>
> Per Will's request this builds on the work by Jordan and Rob for the
> Adreno
> SMMU support. It applies cleanly ontop of v16 of their series, which
> can be
> found at
> https://lore.kernel.org/linux-arm-msm/20200901164707.2645413-1-robdclark@gmail.com/
>
Thanks for working on this, I have tested this on qcom platforms
where firmware does these shenanigans(most android) and this series
works well and where firmware doesn't do all this (chrome) and no
regressions there. Review and test tags given on individual patches.
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