All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: iommu@lists.linux-foundation.org,
	Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra@vger.kernel.org,
	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 18:12:51 +0300	[thread overview]
Message-ID: <ca70b07a-608a-51b3-3c30-ff04bdf8bcc0@gmail.com> (raw)
In-Reply-To: <20210325130332.778208-2-thierry.reding@gmail.com>

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.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Will Deacon <will@kernel.org>,
	 Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: linux-tegra@vger.kernel.org, iommu@lists.linux-foundation.org,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-arm-kernel@lists.infradead.org,
	Jon Hunter <jonathanh@nvidia.com>
Subject: Re: [PATCH 1/9] memory: tegra: Move internal data structures into separate header
Date: Thu, 25 Mar 2021 18:12:51 +0300	[thread overview]
Message-ID: <ca70b07a-608a-51b3-3c30-ff04bdf8bcc0@gmail.com> (raw)
In-Reply-To: <20210325130332.778208-2-thierry.reding@gmail.com>

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.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@gmail.com>,
	Will Deacon <will@kernel.org>,
	 Robin Murphy <robin.murphy@arm.com>,
	Joerg Roedel <joro@8bytes.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Cc: iommu@lists.linux-foundation.org,
	Jon Hunter <jonathanh@nvidia.com>,
	Nicolin Chen <nicolinc@nvidia.com>,
	linux-tegra@vger.kernel.org,
	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 18:12:51 +0300	[thread overview]
Message-ID: <ca70b07a-608a-51b3-3c30-ff04bdf8bcc0@gmail.com> (raw)
In-Reply-To: <20210325130332.778208-2-thierry.reding@gmail.com>

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.

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

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

Thread overview: 69+ 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 ` Thierry Reding
2021-03-25 13:03 ` Thierry Reding
2021-03-25 13:03 ` [PATCH 1/9] memory: tegra: Move internal data structures into separate header Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 15:12   ` Dmitry Osipenko [this message]
2021-03-25 15:12     ` Dmitry Osipenko
2021-03-25 15:12     ` Dmitry Osipenko
2021-03-25 15:52     ` Thierry Reding
2021-03-25 15:52       ` Thierry Reding
2021-03-25 15:52       ` Thierry Reding
2021-03-25 16:11       ` Dmitry Osipenko
2021-03-25 16:11         ` Dmitry Osipenko
2021-03-25 16:11         ` Dmitry Osipenko
2021-03-26 13:21         ` Dmitry Osipenko
2021-03-26 13:21           ` 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   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03 ` [PATCH 3/9] memory: tegra: Implement SID override programming Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 14:27     ` Robin Murphy
2021-03-25 14:27     ` Robin Murphy
2021-03-25 15:02     ` Thierry Reding
2021-03-25 15:02       ` Thierry Reding
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 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 14:27     ` Robin Murphy
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 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 14:27     ` Robin Murphy
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   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03 ` [PATCH 7/9] iommu/arm-smmu: Use Tegra implementation on Tegra186 Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 14:27   ` Robin Murphy
2021-03-25 14:27     ` Robin Murphy
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   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03 ` [PATCH 9/9] arm64: tegra: Enable SMMU support on Tegra194 Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-25 13:03   ` Thierry Reding
2021-03-26 15:29 ` [PATCH 0/9] arm64: tegra: Prevent early SMMU faults Dmitry Osipenko
2021-03-26 15:29   ` Dmitry Osipenko
2021-03-26 15:29   ` Dmitry Osipenko
2021-03-26 16:35   ` Thierry Reding
2021-03-26 16:35     ` Thierry Reding
2021-03-26 16:35     ` Thierry Reding
2021-03-26 16:55     ` Dmitry Osipenko
2021-03-26 16:55       ` Dmitry Osipenko
2021-03-26 16:55       ` Dmitry Osipenko
2021-03-26 22:05       ` Dmitry Osipenko
2021-03-26 22:05         ` 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=ca70b07a-608a-51b3-3c30-ff04bdf8bcc0@gmail.com \
    --to=digetx@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=robin.murphy@arm.com \
    --cc=thierry.reding@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.