mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mikko Perttunen <cyndis@kapsi.fi>
To: Thierry Reding <thierry.reding@gmail.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Mikko Perttunen <mperttunen@nvidia.com>,
	Mian Yousaf Kaukab <ykaukab@suse.de>,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] arm64: tegra: Mark BPMP channels as no-memory-wc
Date: Wed, 22 Jun 2022 16:29:03 +0300	[thread overview]
Message-ID: <9e80da1f-60e9-5528-3636-6443461fb207@kapsi.fi> (raw)
In-Reply-To: <20220622132300.1746201-2-cyndis@kapsi.fi>

On 22.6.2022 16.23, Mikko Perttunen wrote:
> From: Mikko Perttunen <mperttunen@nvidia.com>
> 
> The Tegra SYSRAM contains regions access to which is restricted to
> certain hardware blocks on the system, and speculative accesses to
> those will cause issues.
> 
> Patch 'misc: sram: Only map reserved areas in Tegra SYSRAM' attempted
> to resolve this by only mapping the regions specified in the device
> tree on the assumption that there are no such restricted areas within
> the 64K-aligned area of memory that contains the memory we wish to map.
> 
> Turns out this assumption is wrong, as there are such areas above the
> 4K pages described in the device trees. As such, we need to use the
> bigger hammer that is no-memory-wc, which causes the memory to be
> mapped as Device memory to which speculative accesses are disallowed.
> 
> As such, the previous patch in the series,
>    'firmware: tegra: bpmp: do only aligned access to IPC memory area',
> is required with this patch to make the BPMP driver only issue aligned
> memory accesses as those are also required with Device memory.
> 
> Fixes: fec29bf04994 ("misc: sram: Only map reserved areas in Tegra SYSRAM")
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---

FWIW, with this, the aforementioned patch to misc/sram is redundant. It 
doesn't hurt, but doesn't really help either. Whether or not it should 
be reverted, I have no opinion.

Thanks,
Mikko

>   arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
>   arch/arm64/boot/dts/nvidia/tegra194.dtsi | 1 +
>   arch/arm64/boot/dts/nvidia/tegra234.dtsi | 1 +
>   3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> index 0e9afc3e2f26..9eca18b54698 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
> @@ -1820,6 +1820,7 @@ sram@30000000 {
>   		#address-cells = <1>;
>   		#size-cells = <1>;
>   		ranges = <0x0 0x0 0x30000000 0x50000>;
> +		no-memory-wc;
>   
>   		cpu_bpmp_tx: sram@4e000 {
>   			reg = <0x4e000 0x1000>;
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index d1f8248c00f4..3fdb0b852718 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -2684,6 +2684,7 @@ sram@40000000 {
>   		#address-cells = <1>;
>   		#size-cells = <1>;
>   		ranges = <0x0 0x0 0x40000000 0x50000>;
> +		no-memory-wc;
>   
>   		cpu_bpmp_tx: sram@4e000 {
>   			reg = <0x4e000 0x1000>;
> diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> index cb3af539e477..0213a7e3dad0 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
> @@ -1325,6 +1325,7 @@ sram@40000000 {
>   		#address-cells = <1>;
>   		#size-cells = <1>;
>   		ranges = <0x0 0x0 0x40000000 0x80000>;
> +		no-memory-wc;
>   
>   		cpu_bpmp_tx: sram@70000 {
>   			reg = <0x70000 0x1000>;

  reply	other threads:[~2022-06-22 13:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22 13:22 [PATCH 1/2] firmware: tegra: bpmp: do only aligned access to IPC memory area Mikko Perttunen
2022-06-22 13:23 ` [PATCH 2/2] arm64: tegra: Mark BPMP channels as no-memory-wc Mikko Perttunen
2022-06-22 13:29   ` Mikko Perttunen [this message]
2022-06-23  9:36     ` Yousaf Kaukab

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=9e80da1f-60e9-5528-3636-6443461fb207@kapsi.fi \
    --to=cyndis@kapsi.fi \
    --cc=gregkh@linuxfoundation.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mperttunen@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=ykaukab@suse.de \
    /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

all inboxes | Powered by JetHome®