linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: Rob Herring <robh@kernel.org>, Will Deacon <will@kernel.org>,
	Joerg Roedel <joro@8bytes.org>,
	Linux IOMMU <iommu@lists.linux-foundation.org>,
	Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra <linux-tegra@vger.kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v3 2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string
Date: Mon, 21 Jun 2021 16:11:55 +0200	[thread overview]
Message-ID: <YNCeK9cdMPf+serd@orome.fritz.box> (raw)
In-Reply-To: <14551e79-853d-471f-bb5e-0d2d6581a9b6@canonical.com>


[-- Attachment #1.1: Type: text/plain, Size: 5100 bytes --]

On Mon, Jun 21, 2021 at 08:46:54AM +0200, Krzysztof Kozlowski wrote:
> On 18/06/2021 21:47, Rob Herring wrote:
> > On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding <thierry.reding@gmail.com> wrote:
> >>
> >> From: Thierry Reding <treding@nvidia.com>
> >>
> >> The ARM SMMU instantiations found on Tegra186 and later need inter-
> >> operation with the memory controller in order to correctly program
> >> stream ID overrides.
> >>
> >> Furthermore, on Tegra194 multiple instances of the SMMU can gang up
> >> to achieve higher throughput. In order to do this, they have to be
> >> programmed identically so that the memory controller can interleave
> >> memory accesses between them.
> >>
> >> Add the Tegra186 compatible string to make sure the interoperation
> >> with the memory controller can be enabled on that SoC generation.
> >>
> >> Signed-off-by: Thierry Reding <treding@nvidia.com>
> >> ---
> >>  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
> >>  1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> >> index 9d27aa5111d4..1181b590db71 100644
> >> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> >> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
> >> @@ -54,8 +54,14 @@ properties:
> >>            - const: arm,mmu-500
> >>        - description: NVIDIA SoCs that program two ARM MMU-500s identically
> >>          items:
> >> +      - description: NVIDIA SoCs that require memory controller interaction
> > 
> > This is not valid jsonschema:
> > 
> > /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> > properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
> > must be fixed:
> > None is not of type 'object', 'boolean'
> > None is not of type 'array'
> > from schema $id: http://json-schema.org/draft-07/schema#
> > /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> > properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
> > must be fixed:
> > None is not of type 'object'
> > None is not of type 'array'
> > from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
> > /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> > properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
> > must be fixed:
> > None is not of type 'object'
> > None is not of type 'array'
> > from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
> > /builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
> > properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
> > must be fixed:
> > [{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
> > 'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
> > type 'object'
> > {'const': 'nvidia,tegra194-smmu'} is not of type 'string'
> > {'const': 'nvidia,tegra186-smmu'} is not of type 'string'
> > from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
> > 
> > 
> > This was not reviewed nor tested since the DT list was not Cc'ed.
> 
> Ugh, I see now weird empty item on a list... and not only DT list was
> skipped - Thierry did not Cc you either.

This seemed like a too trivial addition to waste Rob's time on, so I
didn't add him (or the DT list for that matter) on Cc. The ARM SMMU
maintainers had reviewed this, which seemed like it was enough for what
the DT bindings change was doing.

In any case, I clearly should've checked the DT binding check output
more carefully. It's rather messy for Tegra because there's quite a few
that we haven't converted yet. I'll have to resume my effort to convert
the remaining ones and fixup the device trees so that we can actually
run the DT binding and DTB validation checks more usefully.

> My bad, I did not check that patch thoroughly before applying.
> 
> Thierry, please Cc folks mentioned by get_maintainer.pl. Either sent a
> fix or a revert, if fix needs more time.

I've sent out a follow-up fix that removes the two bogus lines. It looks
like that was the result of a bad conflict resolution on my part.

> Additionally, why the patch changes reg to "minItems: 1" for
> nvidia,tegra194-smmu?

This is because originally the Tegra194 SMMU nodes were supposed to only
represent a "dual" instance. However, on Tegra194 there are three SMMU
instances in total, with the third instance (dedicated for isochronous
traffic) being completely separate and having only a single range of
registers.

That third instance was previously supposed to be covered by the normal
"arm,mmu-500" compatible string, but given that we really need that
interoperation between SMMU and memory controller for SID override
programming, we need the Tegra-specific compatible for the ISO instance
of the SMMU as well. And since that uses only one set of registers,
minItems had to become 1.

Thierry

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-06-21 14:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-03 16:46 [PATCH v3 0/9] arm64: tegra: Prevent early SMMU faults Thierry Reding
2021-06-03 16:46 ` [PATCH v3 1/9] memory: tegra: Implement SID override programming Thierry Reding
2021-06-03 16:46 ` [PATCH v3 2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string Thierry Reding
2021-06-18 19:47   ` Rob Herring
2021-06-21  6:46     ` Krzysztof Kozlowski
2021-06-21 14:11       ` Thierry Reding [this message]
2021-06-21 15:54         ` Will Deacon
2021-06-21 16:03           ` Thierry Reding
2021-06-03 16:46 ` [PATCH v3 3/9] iommu/arm-smmu: Implement ->probe_finalize() Thierry Reding
     [not found]   ` <CGME20210615180133eucas1p2563c2a173eca1fb5a1c5ccf654c23778@eucas1p2.samsung.com>
2021-06-15 18:01     ` Marek Szyprowski
2021-06-15 18:08       ` Robin Murphy
2021-06-15 18:12       ` Krishna Reddy
2021-06-15 18:21         ` Will Deacon
2021-06-15 19:50           ` Will Deacon
2021-06-03 16:46 ` [PATCH v3 4/9] iommu/arm-smmu: tegra: Detect number of instances at runtime Thierry Reding
2021-06-03 16:46 ` [PATCH v3 5/9] iommu/arm-smmu: tegra: Implement SID override programming Thierry Reding
2021-06-03 16:46 ` [PATCH v3 6/9] iommu/arm-smmu: Use Tegra implementation on Tegra186 Thierry Reding
2021-06-03 16:46 ` [PATCH v3 7/9] arm64: tegra: Use correct compatible string for Tegra186 SMMU Thierry Reding
2021-06-03 16:46 ` [PATCH v3 8/9] arm64: tegra: Hook up memory controller to SMMU on Tegra186 Thierry Reding
2021-06-03 16:46 ` [PATCH v3 9/9] arm64: tegra: Enable SMMU support on Tegra194 Thierry Reding
2021-06-03 19:51 ` (subset) [PATCH v3 0/9] arm64: tegra: Prevent early SMMU faults Krzysztof Kozlowski
2021-06-11  6:48 ` Krzysztof Kozlowski
2021-06-11 12:05   ` Thierry Reding

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=YNCeK9cdMPf+serd@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=will@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).