[PATCH v7 16/19] arm64: dts: allwinner: Add Allwinner H616 .dtsi file

[Jernej Škrabec]

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 at 40000000 {
> > > > +			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 at 4020000 {
> > > > +			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