linux-kernel - Re: [RFC PATCH] ARM: dts: stm32: fix SDRAM size on stm32f469-disco

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: <CABGWkvrAdiVa9emp29YM84uSTCMUWGRmH61RziNJ+-mPun_1aA@mail.gmail.com>
Date:   Sun, 10 Sep 2023 16:31:11 +0200
From:   Dario Binacchi <dario.binacchi@...rulasolutions.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     linux-kernel@...r.kernel.org,
        Amarula patchwork <linux-amarula@...rulasolutions.com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Conor Dooley <conor+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-stm32@...md-mailman.stormreply.com
Subject: Re: [RFC PATCH] ARM: dts: stm32: fix SDRAM size on stm32f469-disco

Hello Arnd,

On Sat, Sep 9, 2023 at 4:28 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Mon, Sep 4, 2023, at 20:05, Dario Binacchi wrote:
> > The board is equipped with a 128Mbit SDRAM.
> > 128Mbit = 16 Mbyte = 16,777,216 bytes = 0x1000000.
> >
> > Fixes: 626e7ea00215 ("ARM: DT: stm32: move dma translation to board files")
> > Link: https://www.st.com/en/evaluation-tools/32f469idiscovery.html
> > Signed-off-by: Dario Binacchi <dario.binacchi@...rulasolutions.com>
> >
> > ---
> >
> >  arch/arm/boot/dts/st/stm32f469-disco.dts | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/boot/dts/st/stm32f469-disco.dts
> > b/arch/arm/boot/dts/st/stm32f469-disco.dts
> > index cbbd521bf010..f173a5892b7d 100644
> > --- a/arch/arm/boot/dts/st/stm32f469-disco.dts
> > +++ b/arch/arm/boot/dts/st/stm32f469-disco.dts
> > @@ -84,7 +84,7 @@ vdd_dsi: vdd-dsi {
> >       };
> >
> >       soc {
> > -             dma-ranges = <0xc0000000 0x0 0x10000000>;
> > +             dma-ranges = <0xc0000000 0x0 0x1000000>;
> >       };
>
> The dma-ranges should be independent of the installed
> memory, they usually reflect the addressing capabilities
> of the bus, so this patch should not be needed.

Thank you for the explanation.

Question, could I then use this node to describe the installed memory?

memory@...00000 {
            device_type = "memory";
            reg = <0xC0000000 0x1000000>;
};

I recently submitted this series to U-Boot
(https://patchwork.ozlabs.org/project/uboot/patch/20230903205703.662080-5-dario.binacchi@amarulasolutions.com/),
and I would like to allocate the framebuffer by retrieving the correct
information from the device tree, without wiring anything in the code.

Thanks and regards,

Dario

>
>       Arnd



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@...rulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@...rulasolutions.com

www.amarulasolutions.com