From: Andy Gross <andy.gross@linaro.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Rob Herring <robh@kernel.org>, Ohad Ben-Cohen <ohad@wizery.com>,
Stephen Boyd <sboyd@codeaurora.org>,
Mark Rutland <mark.rutland@arm.com>,
Rob Clark <robdclark@gmail.com>,
Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-remoteproc@vger.kernel.org, devicetree@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document
Date: Thu, 1 Sep 2016 15:46:58 -0500 [thread overview]
Message-ID: <20160901204658.GF24683@hector.attlocal.net> (raw)
In-Reply-To: <b7314a89-2215-4961-6e8a-be5ef536624a@linaro.org>
On Thu, Sep 01, 2016 at 05:58:17PM +0300, Stanimir Varbanov wrote:
> Hi,
>
> Cc: Marek
>
> On 08/30/2016 08:17 PM, Bjorn Andersson wrote:
> > On Mon 29 Aug 04:48 PDT 2016, Stanimir Varbanov wrote:
> >
> > [..]
> >>> Trying to wrap my head around how the iommu part works here. The
> >>> downstream code seems to indicate that this is a "generic" secure iommu
> >>> interface - used by venus, camera and kgsl; likely for dealing with DRM
> >>> protected buffers.
> >>
> >> The secure iommu interface is for content protected buffers. But these
> >> secure iommu contexts aren't used by msm DRM nor Venus in mainline. In
> >> Venus case I use non-secure iommu context for data buffers.
> >>
> >
> > We must consider the case when DRM, VFE and Venus handles protected
> > buffers.
>
> That would be interesting topic.
>
> >
> >>>
> >>> As such the iommu tables are not part of the venus rproc; I believe they
> >>> should either be tied into the msm-iommu driver or perhaps exposed as
> >>> its own iommu(?).
> >>
> >> The page tables are in msm-iommu driver.
> >>
> >
> > So, just to verify your answer, the msm-iommu driver will handle both
> > protected and unprotected?
>
> yes, at least for Venus case, the secured buffers are tied to different
> iommu contexts (and stream IDs). But this needs to be verified more
> carefully.
>
> >
> >>>
> >>>
> >>> But I presume from your inclusion that you've concluded that the venus
> >>> firmware we have refuses to execute without these tables at least
> >>> initialized, is this correct?
> >>
> >> Yes, the SMC call for PAS memory-setup will fail if this page table is
> >> not initialized.
> >>
> >
> > If the msm-iommu driver will handle the protected buffers (or if there
> > will be a separate iommu driver for protected buffers) it should issue
> > these calls, to not be dependant on the rproc-venus driver.
>
> For msm8916 we don't have iommu driver in mainline, I don't know what is
> the status with msm8996.
The iommu v2 transparently handles this and removes the requirement for the
specific SCM page tbl init calls. However, the memory still has to be
configured to be accessible from the remote processor.
<snip>
Andy
next prev parent reply other threads:[~2016-09-01 21:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-19 15:53 [PATCH 0/4] Venus remoteproc driver Stanimir Varbanov
2016-08-19 15:53 ` [PATCH 1/4] firmware: qcom: scm: add a video command for state setting Stanimir Varbanov
2016-08-19 15:53 ` [PATCH 2/4] firmware: qcom: scm: add iommu scm calls for pg table Stanimir Varbanov
2016-08-22 16:29 ` kbuild test robot
2016-08-24 18:35 ` Gupta, Puja
2016-08-25 9:08 ` Stanimir Varbanov
2016-08-30 21:15 ` Andy Gross
2016-08-19 15:53 ` [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document Stanimir Varbanov
2016-08-23 17:32 ` Rob Herring
2016-08-23 18:21 ` Bjorn Andersson
2016-08-24 15:36 ` Stanimir Varbanov
2016-08-25 0:05 ` Bjorn Andersson
2016-08-25 11:10 ` Stanimir Varbanov
2016-08-26 22:23 ` Bjorn Andersson
2016-08-29 11:48 ` Stanimir Varbanov
2016-08-30 17:17 ` Bjorn Andersson
2016-09-01 14:58 ` Stanimir Varbanov
2016-09-01 20:46 ` Andy Gross [this message]
2016-09-02 11:52 ` Marek Szyprowski
2016-09-02 20:12 ` Bjorn Andersson
2016-09-07 11:52 ` Stanimir Varbanov
2016-09-15 8:46 ` Marek Szyprowski
2016-08-19 15:53 ` [PATCH 4/4] remoteproc: qcom: add Venus video core firmware loader driver Stanimir Varbanov
2016-10-18 16:23 ` Stanimir Varbanov
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=20160901204658.GF24683@hector.attlocal.net \
--to=andy.gross@linaro.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=ohad@wizery.com \
--cc=robdclark@gmail.com \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=srinivas.kandagatla@linaro.org \
--cc=stanimir.varbanov@linaro.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