From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Georgi Djakov <georgi.djakov@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Jon Hunter <jonathanh@nvidia.com>,
linux-tegra@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [RFC 2/2] dt-bindings: firmware: tegra186-bpmp: Document interconnects property
Date: Wed, 29 Jan 2020 10:36:02 +0100 [thread overview]
Message-ID: <20200129093602.GC2479935@ulmo> (raw)
In-Reply-To: <d56618e1-8940-65ae-381e-796e44bcf537@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
On Tue, Jan 28, 2020 at 10:27:00PM +0300, Dmitry Osipenko wrote:
> 27.01.2020 15:21, Thierry Reding пишет:
> > On Tue, Jan 21, 2020 at 11:12:11PM +0300, Dmitry Osipenko wrote:
> >> 21.01.2020 18:54, Thierry Reding пишет:
> >>> On Tue, Jan 21, 2020 at 05:18:43PM +0200, Georgi Djakov wrote:
> >>>> On 1/21/20 16:10, Thierry Reding wrote:
> > [...]
> >>>>> I'm not sure if that TEGRA_ICC_EMEM makes a lot of sense. It's always
> >>>>> going to be the same and it's arbitrarily defined, so it's effectively
> >>>>> useless. But other than that it looks good.
> >>>>
> >>>> Well, in most cases the target would be the EMEM, so that's fine. I have seen
> >>>> that other vendors that may have an additional internal memory, especially
> >>>> dedicated to some DSPs and in such cases the bandwidth needs are different for
> >>>> the two paths (to internal memory and DDR).
> >>>
> >>> Most chips have a small internal memory that can be used, though it
> >>> seldomly is. However, in that case I would expect the target to be a
> >>> completely different device, so it'd look more like this:
> >>>
> >>> interconnects = <&mc TEGRA186_MEMORY_CLIENT_BPMPR &iram>,
> >>> ...;
> >>>
> >>> I don't think EMEM has any "downstream" other than external memory.
> >>
> >> The node ID should be mandatory in terms of interconnect, even if it's a
> >> single node. EMC (provider) != EMEM (endpoint).
> >
> > I don't understand why. An ID only makes sense if you've got multiple
> > endpoints. For example, a regulator is a provider with a single endpoint
> > so we don't specify an ID.
>
> Because this is how ICC binding is defined, unless I'm missing something.
I don't think so. It's defined as "pairs of phandles and interconnect
provider specifiers", which is equivalent to what pretty much all of the
resource bindings define. The #interconnect-cells property defines the
number of cells used for the specifier. In the normal case this would be
1, and the value of the one cell would be the ID of the endpoint. But if
there's only a single endpoint, it's customary to set the number of
cells to 0, in which case only the phandle is required.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-01-29 9:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-14 18:15 [PATCH 1/2] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Thierry Reding
2020-01-14 18:15 ` [RFC 2/2] dt-bindings: firmware: tegra186-bpmp: Document interconnects property Thierry Reding
2020-01-17 15:23 ` Georgi Djakov
2020-01-20 15:06 ` Thierry Reding
2020-01-21 6:53 ` Dmitry Osipenko
2020-01-21 14:10 ` Thierry Reding
2020-01-21 15:18 ` Georgi Djakov
2020-01-21 15:54 ` Thierry Reding
2020-01-21 20:12 ` Dmitry Osipenko
2020-01-26 21:56 ` Dmitry Osipenko
2020-01-26 22:03 ` Dmitry Osipenko
2020-01-27 12:52 ` Thierry Reding
2020-01-27 12:49 ` Thierry Reding
2020-02-05 21:34 ` Dmitry Osipenko
2020-01-27 12:21 ` Thierry Reding
2020-01-28 19:27 ` Dmitry Osipenko
2020-01-29 9:36 ` Thierry Reding [this message]
2020-01-29 16:02 ` Dmitry Osipenko
2020-01-29 16:13 ` Georgi Djakov
2020-01-29 16:16 ` Dmitry Osipenko
2020-01-16 19:28 ` [PATCH 1/2] dt-bindings: firmware: Convert Tegra186 BPMP bindings to json-schema Rob Herring
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=20200129093602.GC2479935@ulmo \
--to=thierry.reding@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=digetx@gmail.com \
--cc=georgi.djakov@linaro.org \
--cc=jonathanh@nvidia.com \
--cc=linux-tegra@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).