[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8040051.UxXjYCDM83@jernej-laptop>
Date: Thu, 17 Jun 2021 17:47:29 +0200
From: Jernej Škrabec <jernej.skrabec@...il.com>
To: Andre Przywara <andre.przywara@....com>,
Maxime Ripard <maxime@...no.tech>
Cc: Chen-Yu Tsai <wens@...e.org>, Rob Herring <robh@...nel.org>,
Icenowy Zheng <icenowy@...c.io>,
Samuel Holland <samuel@...lland.org>,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...glegroups.com,
linux-sunxi@...ts.linux.dev, linux-kernel@...r.kernel.org,
Ondrej Jirman <megous@...ous.com>, devicetree@...r.kernel.org
Subject: Re: [PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
Dne četrtek, 17. junij 2021 ob 17:42:42 CEST je Maxime Ripard napisal(a):
> On Wed, Jun 16, 2021 at 11:06:30AM +0100, Andre Przywara wrote:
> > > > + reserved-memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + ranges;
> > > > +
> > > > + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> > > > + secmon_reserved: secmon@...00000 {
> > > > + reg = <0x0 0x40000000 0x0 0x80000>;
> > > > + no-map;
> > > > + };
> > > > + };
> > >
> > > Can't this be added by ATF directly?
> >
> > It actually is, and if you use U-Boot's DT ($fdtcontroladdr), that
> > actually works. But as it stands right now, U-Boot fails to propagate
> > this to any DTB that gets *loaded*. Fixing this requires generic code
> > fixes, so I can't just hack this in for sunxi quickly.
> > So I wanted to keep this around for a while, as missing this is a
> > showstopper for booting Linux.
>
> It looks like we didn't need it for the H6, what makes it any different?
H616 TF-A resides in DRAM and H6 resides in SRAM A2 (IIRC). H616 has much less
useful SRAM due to ARISC removal.
Best regards,
Jernej
>
> > > > + mmc0: mmc@...0000 {
> > > > + compatible = "allwinner,sun50i-h616-mmc",
> > > > + "allwinner,sun50i-a100-
mmc";
> > > > + reg = <0x04020000 0x1000>;
> > > > + clocks = <&ccu CLK_BUS_MMC0>, <&ccu
CLK_MMC0>;
> > > > + clock-names = "ahb", "mmc";
> > > > + resets = <&ccu RST_BUS_MMC0>;
> > > > + reset-names = "ahb";
> > > > + interrupts = <GIC_SPI 35
IRQ_TYPE_LEVEL_HIGH>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&mmc0_pins>;
> > > > + status = "disabled";
> > > > + max-frequency = <150000000>;
> > > > + cap-sd-highspeed;
> > > > + cap-mmc-highspeed;
> > > > + mmc-ddr-3_3v;
> > > > + mmc-ddr-1_8v;
> > >
> > > This is not something you know in the DTSI? It entirely depends on how
> > > the board has been designed.
> >
> > Are you referring just to the last property?
>
> Initially, yes, but the argument is for both...
>
> > This is copying what the driver unconditionally sets for the other
> >
> > SoCs at the moment (minus the H5 screwup):
> > mmc->caps |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;
> >
> > IIUC 1.8V operation requires a 1.8V regulator for vqmmc to actually
> > work, so this property alone won't enable anything.
> > But if it's just about the 1.8V property, I can of course move this to
> > the board dts files.
>
> ... Since we've seen boards with only 3.3v or 1.8v wired to vqmmc, so we
> should really just push this to the boards for new SoCs
>
> Maxime
Powered by blists - more mailing lists