From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 704ECC433FE for ; Mon, 14 Nov 2022 22:56:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To:Message-Id:Cc:To :Subject:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=PuJbJ/mqKWZkuEOzdp2ZslKyq5g9sbnblgZfYjeMvCw=; b=ywnk/O7SFmeiydby3ETxeiwHnA E/pp2YbpLa0YOtCGbNQ6ImQx6ov8KYaH7O98fY1vjxCOcDTpCuQYaxCBsEaw4OyEE5Q0j7/qkpQpM HkXFCQBFdVjiFm46wHBUGU+Lm1ZCIFCf56FZbXFLlpxN8DeLYXdorj7pvvZN6doghj6tdE/3Yu78N AhhnkQ14FQ5AocBEG1gYb09SdOXTTEp2ToD3Xt6W7OuDymbs1tO8T2dPQgEVLJ8i5CWLc24Eusqu5 9Xg/+SmsMsZCf5W1JU9wlG3O0oBkmxhv8zdt/cE+g40CT+u/MjVVy0eu4AFMIQtRfTVhn1DlQbiJW iNfqNI4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouiM2-005jzg-Ry; Mon, 14 Nov 2022 22:55:02 +0000 Received: from m-r1.th.seeweb.it ([5.144.164.170]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouiLy-005jyV-QN for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 22:55:01 +0000 Received: from [192.168.2.144] (bband-dyn193.178-41-216.t-com.sk [178.41.216.193]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id 471231F881; Mon, 14 Nov 2022 23:54:52 +0100 (CET) Date: Mon, 14 Nov 2022 23:54:46 +0100 From: Martin Botka Subject: Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1 To: Jernej =?iso-8859-2?q?=A9krabec?= Cc: martin.botka1@gmail.com, ~postmarketos/upstreaming@lists.sr.ht, Konrad Dybcio , AngeloGioacchino Del Regno , Marijn Suijten , Jami Kettunen , Paul Bouchara , Jan Trmal , Tom , Rob Herring , Krzysztof Kozlowski , Chen-Yu Tsai , Samuel Holland , Maxime Ripard , Andre Przywara , Conley Lee , Andrew Lunn , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <4534857.CvnuH1ECHv@jernej-laptop> References: <20221114214452.1993744-1-martin.botka@somainline.org> <20221114214452.1993744-2-martin.botka@somainline.org> <4534857.CvnuH1ECHv@jernej-laptop> X-Mailer: geary/40.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_145459_201720_2A85742B X-CRM114-Status: GOOD ( 38.57 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-2"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Nov 14 2022 at 11:30:17 PM +01:00:00, Jernej =A9krabec = wrote: > Hi Martin, > = > I was just writing new e-mail as response to v2. You should wait at = > least a > day or two, usually more, before sending new version. Others will = > likely have > some more comments. And there is also no rush. Until PMIC series is = > merged, > this will not go anywhere. Since there is only this week until cut = > off date for > DT updates for kernel 6.2, it's most likely that this will land in = > 6.3. And > that gives as a few weeks (month) more. Yep. Was hoping for 5.2 thus the frequent updates. Will take it slow = then since 5.3 :) > = > See comments below. > = > Dne ponedeljek, 14. november 2022 ob 22:44:49 CET je Martin Botka = > napisal(a): >> CB1 is Compute Module style board that plugs into Rpi board style = >> adapter or >> Manta 3D printer boards (M4P/M8P). >> = >> The board has: >> H616 SoC >> 1GB of RAM >> AXP313A PMIC >> = >> And the actual boards that CB1 plugs in are just extension to it = >> with ports >> and thus are not split in DT. >> = >> Boards have: >> 4x (3x for Manta boards) USB and 1 USB OTG. >> SDcard slot for loading images. >> Ethernet port wired to the internal PHY. >> 2x HDMI 2.0. > = > H616 has only one HDMI output. Unless there is some additional chip = > for some > conversion, only one HDMI port can work. Yes correct. But the Rpi adapter and Manta boards also support Rpi Compute Module 4 which has 2 HDMI outputs. The chip itself ofc doesnt support this on CB1. Same goes for DSI/CSI = ports on the boards and the 4x USB on Rpi adapter. It is indeed a bit of a mess. > = >> Power and Status LEDs. >> = >> Currently working: >> Booting >> USB >> UART >> = >> Signed-off-by: Martin Botka >> --- >> Changes in V2: >> Add proper board compatible >> Add regulator prefix for vcc5v >> Drop okay status from PMIC >> Drop standby_param >> Changes in V3: >> Change copyright to me >> regulator_vcc5v to regulator-vcc5v >> Drop ehci0 and ohci0 >> arch/arm64/boot/dts/allwinner/Makefile | 1 + >> .../dts/allwinner/sun50i-h616-biqu-cb1.dts | 178 = >> ++++++++++++++++++ >> 2 files changed, 179 insertions(+) >> create mode 100644 = >> arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts >> = >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile >> b/arch/arm64/boot/dts/allwinner/Makefile index = >> 6a96494a2e0a..223f1be73541 >> 100644 >> --- a/arch/arm64/boot/dts/allwinner/Makefile >> +++ b/arch/arm64/boot/dts/allwinner/Makefile >> @@ -38,5 +38,6 @@ dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h6-pine-h64.dtb >> dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h6-pine-h64-model-b.dtb >> dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h6-tanix-tx6.dtb >> dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h6-tanix-tx6-mini.dtb >> +dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h616-biqu-cb1.dtb >> dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h616-orangepi-zero2.dtb >> dtb-$(CONFIG_ARCH_SUNXI) +=3D sun50i-h616-x96-mate.dtb >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts >> b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts new file = >> mode >> 100644 >> index 000000000000..86b5aca9b53e >> --- /dev/null >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-biqu-cb1.dts >> @@ -0,0 +1,178 @@ >> +// SPDX-License-Identifier: (GPL-2.0+ or MIT) >> +/* >> + * Copyright (C) 2022 Martin Botka . >> + */ >> + >> +/dts-v1/; >> + >> +#include "sun50i-h616.dtsi" >> + >> +#include >> +#include >> +#include >> + >> +/ { >> + model =3D "BIQU CB1"; >> + compatible =3D "biqu,cb1", "allwinner,sun50i-h616"; >> + >> + aliases { >> + serial0 =3D &uart0; >> + }; >> + >> + chosen { >> + stdout-path =3D "serial0:115200n8"; >> + }; >> + >> + leds { >> + compatible =3D "gpio-leds"; >> + >> + led-0 { >> + function =3D LED_FUNCTION_POWER; >> + color =3D ; >> + gpios =3D <&pio 2 12 GPIO_ACTIVE_HIGH>; /* > PC12 */ >> + default-state =3D "on"; >> + }; >> + >> + led-1 { >> + function =3D LED_FUNCTION_STATUS; >> + color =3D ; >> + gpios =3D <&pio 2 13 GPIO_ACTIVE_HIGH>; /* > PC13 */ >> + }; >> + }; >> + >> + reg_vcc5v: regulator-vcc5v { >> + /* board wide 5V supply directly from the USB-C socket > */ >> + compatible =3D "regulator-fixed"; >> + regulator-name =3D "vcc-5v"; >> + regulator-min-microvolt =3D <5000000>; >> + regulator-max-microvolt =3D <5000000>; >> + regulator-always-on; >> + }; >> + >> + reg_usb1_vbus: regulator-usb1-vbus { >> + compatible =3D "regulator-fixed"; >> + regulator-name =3D "usb1-vbus"; >> + regulator-min-microvolt =3D <5000000>; >> + regulator-max-microvolt =3D <5000000>; >> + vin-supply =3D <®_vcc5v>; >> + enable-active-high; >> + gpio =3D <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */ >> + }; >> +}; >> + >> +&ehci1 { >> + status =3D "okay"; >> +}; >> + >> +&ehci2 { >> + status =3D "okay"; >> +}; >> + >> +&ehci3 { >> + status =3D "okay"; >> +}; >> + >> +&mmc0 { >> + vmmc-supply =3D <®_dldo1>; >> + cd-gpios =3D <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */ >> + no-1-8-v; > = > Above property is not needed. If you don't provide vqmmc-supply with = > 1.8 V > regulator, it won't be used. > = >> + bus-width =3D <4>; >> + status =3D "disabled"; > = > Why is set to disabled? If it's not a typo, remove whole node. It = > could be > added later when it works. Would not removing it also make PMIC node useless as the regulators = wont be used and thus should be technically removed ? > = >> +}; >> + >> +&ohci1 { >> + status =3D "okay"; >> +}; >> + >> +&ohci2 { >> + status =3D "okay"; >> +}; >> + >> +&ohci3 { >> + status =3D "okay"; >> +}; >> + >> +&r_i2c { >> + status =3D "okay"; >> + >> + axp1530: pmic@36 { >> + compatible =3D "x-powers,axp1530"; > = > I just checked datasheet and it really seems that it supports only = > I2C. > Anyway, rather than using axp1530 compatible, introduce axp313a = > compatible > instead. Will do in V2 for drivers later. > = >> + reg =3D <0x36>; >> + wakeup-source; >> + >> + regulators{ >> + reg_dcdc1: dcdc1 { >> + regulator-name =3D "axp1530-dcdc1"; >> + regulator-min-microvolt =3D > <500000>; >> + regulator-max-microvolt =3D > <3400000>; > = > This one is most likely used by CPU. If so, you should set = > appropriate range > according to CPU needs, which are 810 - 1100 mV. > = >> + regulator-step-delay-us =3D <25>; >> + regulator-final-delay-us =3D <50>; >> + regulator-always-on; >> + }; >> + >> + reg_dcdc2: dcdc2 { >> + regulator-name =3D "axp1530-dcdc2"; >> + regulator-min-microvolt =3D > <500000>; >> + regulator-max-microvolt =3D > <1540000>; > = > This one is most likely used by GPU. Its range must also be adjusted = > to GPU > needs. > = >> + regulator-step-delay-us =3D <25>; >> + regulator-final-delay-us =3D <50>; >> + regulator-ramp-delay =3D <200>; >> + regulator-always-on; >> + }; >> + >> + reg_dcdc3: dcdc3 { >> + regulator-name =3D "axp1530-dcdc3"; >> + regulator-min-microvolt =3D > <500000>; >> + regulator-max-microvolt =3D > <1840000>; > = > This one looks like it supplies DRAM. You should set both min and max = > to > actual DRAM needs. > = >> + regulator-step-delay-us =3D <25>; >> + regulator-final-delay-us =3D <50>; >> + regulator-always-on; >> + }; >> + >> + reg_aldo1: ldo1 { > = > ldo1 -> aldo1 > = >> + regulator-name =3D "axp1530-aldo1"; >> + regulator-min-microvolt =3D > <1800000>; >> + regulator-max-microvolt =3D > <1800000>; >> + regulator-step-delay-us =3D <25>; >> + regulator-final-delay-us =3D <50>; >> + regulator-always-on; >> + }; >> + >> + reg_dldo1: ldo2 { > = > ldo2 -> dldo1 > = > Another issue I see is that you marked all regulators with = > regulator-always- > on; While this works, I don't think this faithfully represent HW. For = > example, > GPU regulator will be enabled by GPU driver when needed, so it = > shouldn't be > marked with always on. > = > There is also RTCLDO, but without schematic it's impossible to say if = > it is > used or not. > = > There are at least a few clues in AXP313A datasheet about which = > regulator is > used for what. See chapter 7.5 in = > https://github.com/bigtreetech/CB1-Kernel/ > blob/kernel-5.16/docs/AXP313A%20datasheet%20V0.1%20- > %2020201105_draft%20version.pdf As for regulators themselves. I have kept them as what downstream = kernel specifies. But until I have schematic in hand and can confirm that they actually = used the correct regulators in the correct place i will stick to stock values. If they in the end = decide to not supply schematic or etc to the public i can test with adjusted values. > = > Best regards, > Jernej > = >> + regulator-name =3D "axp1530-dldo1"; >> + regulator-min-microvolt =3D > <3300000>; >> + regulator-max-microvolt =3D > <3300000>; >> + regulator-step-delay-us =3D <25>; >> + regulator-final-delay-us =3D <50>; >> + regulator-always-on; >> + }; >> + }; >> + }; >> +}; >> + >> +&uart0 { >> + pinctrl-names =3D "default"; >> + pinctrl-0 =3D <&uart0_ph_pins>; >> + status =3D "okay"; >> +}; >> + >> +&usbotg { >> + /* >> + * PHY0 pins are connected to a USB-C socket, but a role switch >> + * is not implemented: both CC pins are pulled to GND. >> + * The VBUS pins power the device, so a fixed peripheral mode >> + * is the best choice. >> + * The board can be powered via GPIOs, in this case port0 *can* >> + * act as a host (with a cable/adapter ignoring CC), as VBUS is >> + * then provided by the GPIOs. Any user of this setup would >> + * need to adjust the DT accordingly: dr_mode set to "host", >> + * enabling OHCI0 and EHCI0. >> + */ >> + dr_mode =3D "peripheral"; >> + status =3D "okay"; >> +}; >> + >> +&usbphy { >> + usb1_vbus-supply =3D <®_usb1_vbus>; >> + status =3D "okay"; >> +}; > = > = > = > = Best Regards, Martin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel