Linux IOMMU Development
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	Will Deacon <will@kernel.org>, Jon Hunter <jonathanh@nvidia.com>,
	iommu@lists.linux-foundation.org,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra@vger.kernel.org, Robin Murphy <robin.murphy@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/9] memory: tegra: Move internal data structures into separate header
Date: Thu, 25 Mar 2021 16:52:22 +0100	[thread overview]
Message-ID: <YFyxtq6cwIJNr/Y5@orome.fritz.box> (raw)
In-Reply-To: <ca70b07a-608a-51b3-3c30-ff04bdf8bcc0@gmail.com>


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

On Thu, Mar 25, 2021 at 06:12:51PM +0300, Dmitry Osipenko wrote:
> 25.03.2021 16:03, Thierry Reding пишет:
> > From: Thierry Reding <treding@nvidia.com>
> > 
> > From Tegra20 through Tegra210, either the GART or SMMU drivers need
> > access to the internals of the memory controller driver because they are
> > tightly coupled (in fact, the GART and SMMU are part of the memory
> > controller). On later chips, a separate hardware block implements the
> > SMMU functionality, so this is no longer needed. However, we still want
> > to reuse some of the existing infrastructure on later chips, so split
> > the memory controller internals into a separate header file to avoid
> > conflicts with the implementation on newer chips.
> > 
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> >  drivers/iommu/tegra-gart.c      |  2 +-
> >  drivers/iommu/tegra-smmu.c      |  2 +-
> >  drivers/memory/tegra/mc.h       |  2 +-
> >  drivers/memory/tegra/tegra186.c | 12 ++++---
> >  include/soc/tegra/mc-internal.h | 62 +++++++++++++++++++++++++++++++++
> >  include/soc/tegra/mc.h          | 50 --------------------------
> >  6 files changed, 72 insertions(+), 58 deletions(-)
> >  create mode 100644 include/soc/tegra/mc-internal.h
> 
> What about to make T186 to re-use the existing tegra_mc struct? Seems
> there is nothing special in that struct which doesn't fit for the newer
> SoCs. Please notice that both SMMU and GART are already optional and all
> the SoC differences are specified within the tegra_mc_soc. It looks to
> me that this could be a much nicer and cleaner variant.

The problem is that much of the interesting bits in tegra_mc_soc are
basically incompatible between the two. For instance the tegra_mc_client
and tegra186_mc_client structures, while they have the same purpose,
have completely different content. I didn't see a way to unify that
without overly complicating things by making half of the fields
basically optional on one or the other SoC generation.

Maybe one option would be to split tegra_mc into a tegra_mc_common and
then derive tegra_mc and tegra186_mc from that. That way we could share
the common bits while still letting the chip-specific differences be
handled separately.

Thierry

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

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

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2021-03-25 15:52 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 13:03 [PATCH 0/9] arm64: tegra: Prevent early SMMU faults Thierry Reding
2021-03-25 13:03 ` [PATCH 1/9] memory: tegra: Move internal data structures into separate header Thierry Reding
2021-03-25 15:12   ` Dmitry Osipenko
2021-03-25 15:52     ` Thierry Reding [this message]
2021-03-25 16:11       ` Dmitry Osipenko
2021-03-26 13:21         ` Dmitry Osipenko
2021-03-25 13:03 ` [PATCH 2/9] memory: tegra: Add memory client IDs to tables Thierry Reding
2021-03-25 13:03 ` [PATCH 3/9] memory: tegra: Implement SID override programming Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 15:02     ` Thierry Reding
2021-03-25 13:03 ` [PATCH 4/9] iommu/arm-smmu: Implement ->probe_finalize() Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 13:03 ` [PATCH 5/9] iommu/arm-smmu: tegra: Detect number of instances at runtime Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 13:03 ` [PATCH 6/9] iommu/arm-smmu: tegra: Implement SID override programming Thierry Reding
2021-03-25 13:03 ` [PATCH 7/9] iommu/arm-smmu: Use Tegra implementation on Tegra186 Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 13:03 ` [PATCH 8/9] arm64: tegra: Hook up memory controller to SMMU " Thierry Reding
2021-03-25 13:03 ` [PATCH 9/9] arm64: tegra: Enable SMMU support on Tegra194 Thierry Reding
2021-03-26 15:29 ` [PATCH 0/9] arm64: tegra: Prevent early SMMU faults Dmitry Osipenko
2021-03-26 16:35   ` Thierry Reding
2021-03-26 16:55     ` Dmitry Osipenko
2021-03-26 22:05       ` Dmitry Osipenko

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=YFyxtq6cwIJNr/Y5@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=digetx@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --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