From: Stephen Boyd <swboyd@chromium.org>
To: Vivek Gautam <vivek.gautam@codeaurora.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>,
Andy Gross <agross@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
Sibi Sankar <sibis@codeaurora.org>
Subject: Re: [PATCH] arm64: dts: sdm845: Add iommus property to qup1
Date: Fri, 30 Aug 2019 15:03:22 -0700 [thread overview]
Message-ID: <5d699d2b.1c69fb81.6db46.76a9@mx.google.com> (raw)
In-Reply-To: <5d2e61fc.1c69fb81.afb7a.a64a@mx.google.com>
Quoting Stephen Boyd (2019-07-16 16:47:07)
> Quoting Vivek Gautam (2019-06-12 02:26:20)
> >
> >
> > On 6/11/2019 4:51 AM, Stephen Boyd wrote:
> > > hardware signal like the NS bit and/or the Execution Level. Hopefully
> > > it's a config and then our difference from MTP can be minimized.
> >
> > I don't think SMMU limits any such programming of SIDs. It's a design
> > decision
> > to program few SIDs in TZ/Hyp and allocate the corresponding context banks
> > and create respective mappings. You should be able to see these SMR
> > configurations
> > before kernel boots up. I use a simple T32 command -
> >
> > smmu.add "<name>" <smmu_type> <base_address>
> > smmu.streammaptable <name>
> >
> > e.g. for sdm845 apps_smmu
> >
> > smmu.add "apps" MMU500 a:0x15000000
> > smmu.StreamMapTable apps
> >
> > This dumps all the information regarding the smmu.
>
> Preferably I can see this by using devmem instead of jtag and T32. Do
> you know the address of the register? Otherwise I'll go dig into the
> documentation and try to figure it out.
And this won't really help me will it? I thought the stream ID was "fixed" by
hardware, so it seems sort of weird that we're talking about limiting it in
TZ/hyp. Here's the S2CR table from Cheza in case that is useful.
localhost ~ # mem
Welcome to mem interactive mode (featuring python!)
Available functions:
- r(addr) # Read a single 32-bit word (little endian).
- rm(addr, nbytes) # Read memory at the given addr as a string.
- w(addr, val) # Write a single 32-bit word (little endian).
- wm(addr, val) # Write a string to memory at the given addr.
>>> for x in range(64):
... r(0x15000c00 + (x << 2))
...
0x00000000
0x00000000
0x00000001
0x00000002
0x00000003
0x00000004
0x00000005
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
0x00020000
>
> >
> > >
> > > As far as I can tell, HLOS on SDM845 has always used GPI (yet another
> > > DMA engine) to do the DMA transfers. And the GPI is the hardware block
> > > that uses the SID of 0x6d6 above, so putting that into iommus for the
> > > geniqup doesn't make any sense given that GPI is another node. Can you
> > > confirm this is the case? Furthermore, the SID of 0x6c3 sounds untested?
> > > Has it ever been generated on SDM845 MTP?
> >
> > I will get back with this information.
> >
>
> Any update?
Any news?
next prev parent reply other threads:[~2019-08-30 22:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-04 22:29 [PATCH] arm64: dts: sdm845: Add iommus property to qup1 Stephen Boyd
2019-06-04 22:37 ` Bjorn Andersson
2019-06-04 22:46 ` Stephen Boyd
2019-06-04 22:59 ` Bjorn Andersson
2019-06-05 4:55 ` Vivek Gautam
2019-06-05 20:56 ` Stephen Boyd
2019-06-06 11:17 ` Vivek Gautam
2019-06-06 14:12 ` Marc Gonzalez
2019-06-10 23:21 ` Stephen Boyd
2019-06-12 9:26 ` Vivek Gautam
2019-07-16 23:47 ` Stephen Boyd
2019-08-30 22:03 ` Stephen Boyd [this message]
2019-06-04 22:48 ` Doug Anderson
2019-06-04 22:56 ` Bjorn Andersson
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=5d699d2b.1c69fb81.6db46.76a9@mx.google.com \
--to=swboyd@chromium.org \
--cc=agross@kernel.org \
--cc=bjorn.andersson@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sibis@codeaurora.org \
--cc=vivek.gautam@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;
as well as URLs for NNTP newsgroup(s).