linux-kernel - Re: [PATCH v2] ARM: dts: sun8i: v3s: SRAM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGb2v67-QwUpy5ca6CPBgzAYcEVRPT6O1f6+XrgOQyEeF+B1aQ@mail.gmail.com>
Date:   Fri, 4 Dec 2020 10:39:58 +0800
From:   Chen-Yu Tsai <wens@...e.org>
To:     Martin Cerveny <m.cerveny@...puter.org>
Cc:     devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Maxime Ripard <mripard@...nel.org>,
        Rob Herring <robh+dt@...nel.org>
Subject: Re: [PATCH v2] ARM: dts: sun8i: v3s: SRAM_C real mapping

On Fri, Dec 4, 2020 at 2:15 AM Martin Cerveny <m.cerveny@...puter.org> wrote:
>
> VideoEngine (cedrus) needs assign dedicated SRAM for decoding.
> SRAM_C1 is usually used for Allwinner platforms.
> Allwinner V3s scale down chip has not SRAM_C1 but only small SRAM_C (44kB).
>
> Result of additional testing:
>
> SRAM_C is mapped in two regions 0x0000_4000 (primary location,
> by Datasheet) (size is 0xb000, probably exact size is 0xb0c0
> and it is mapped to 4k boundary (to 0x0000_ffff))
> and to 0x01d0_4000 (traditional SRAM_C1 region from 0x01d0_0000).
>
> Rest of 0x01d0_0000 are discontinuously filled with R/W register sets
> (probably some internals registers from VE) that I thought to be SRAM too.
>
> Programming register SRAM_CTRL_REG0 (0x01c00_0000) with value 0x7fff_ffff
> switch out whole region 0x01d0_0000-0x01df_ffff and 0x0000_4000-0x0000_ffff
> (dedicate access to VE).
>
> VE/cedrus code use this SRAM region indirectly
> (VE_AVC_SRAM_PORT_OFFSET/VE_AVC_SRAM_PORT_DATA...)
> and it is not influenced by "real" SRAM mapping or size
> so it is working even without this patch.
>
> Signed-off-by: Martin Cerveny <m.cerveny@...puter.org>
> ---
>  arch/arm/boot/dts/sun8i-v3s.dtsi | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
> index e8f304125e2d..bc4b4a0200cb 100644
> --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> @@ -162,17 +162,17 @@ syscon: system-control@...0000 {
>                         #size-cells = <1>;
>                         ranges;
>
> -                       sram_c: sram@...0000 {
> +                       sram_c: sram@...0 {
>                                 compatible = "mmio-sram";
> -                               reg = <0x01d00000 0x80000>;
> +                               reg = <0x4000 0xb000>;
>                                 #address-cells = <1>;
>                                 #size-cells = <1>;
> -                               ranges = <0 0x01d00000 0x80000>;
> +                               ranges = <0 0x4000 0xb000>;
>
>                                 ve_sram: sram-section@0 {
>                                         compatible = "allwinner,sun8i-v3s-sram-c1",

Using C1 in the compatible string is confusing at this point, as the
name is never mentioned in the manual.

Please change it to sram-ve instead. Please also update the binding.

Since the DT patches this depends on haven't been merged yet, please
just do another version of the remaining patches with the changes
included.


ChenYu


>                                                      "allwinner,sun4i-a10-sram-c1";
> -                                       reg = <0x000000 0x80000>;
> +                                       reg = <0x0 0xb000>;
>                                 };
>                         };
>                 };
> --
> 2.25.1
>