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 607F0C4332F for ; Mon, 14 Nov 2022 22:31:44 +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-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N06ObiDtdU/BrrVTp5sHVPux7Fm7ntrfyV/x0qdYns0=; b=gSFl6AIM6cluqM z3SCUZX+tDBrZLmfxPHRaG7F/SVcT19kw7iiZbmkH3AyFHRgaSGouFWuDja1hf0vv7dtRVqAUI165 qtW7lxfvtHDoQQtO3s+ucxLeimuLCPc5ujczgMSTrusHRtVRkTd9PZo7INYnSBQrjfIDLizexIt2V Van6xNUbD9ee9hN26y4em/V5b1U7VaixgmHwRLUvjMn2pjl8pCN763lJsht25pK19wmq4mvxgLfym BtHyG9/Ex2cbjTIZ3JXEB/ZnIYwrpp/5gNds3MCrJz4Q3z52eqipOfnyl8TfZqhDN2+R5dzfNLPve FdjsKJLCN9RUnQtnXWaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouhyM-005L1y-NU; Mon, 14 Nov 2022 22:30:34 +0000 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ouhyJ-005Ky1-6v for linux-arm-kernel@lists.infradead.org; Mon, 14 Nov 2022 22:30:33 +0000 Received: by mail-ej1-x634.google.com with SMTP id ud5so31895130ejc.4 for ; Mon, 14 Nov 2022 14:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=LtL2HZVK+P0c30MAByLL8r0VKNh+zbkLo486TTYNu+g=; b=Sw0ck92xCMstWkQ6ZvwZKX74xCkixNSvsUCpnI83uIw3rNplJk656XAl9UgdJjkHIN HtpE7OULt2bArRwHCQFYA6oW5gU+fNLhKIjKquJw6RBHfkFn2+st97M92Kwe96ZtFE/3 FRtn18gbg72uITYrqioYrV9/eWr2nflQm1HgQpktbZSYEV05uatfbGQJwUQ86On7EvEW TTmyJzUU+PgTi4pYrkGZgBAAqFMK4nMzio2QM3QNd7b7TOC/cNnFkhe1t8ab9K+h0Nih HsVhlYdNS1MA+/2Xdy1IWwtzsQRio9jkvm9D+ngyARcm+0njdi+hzmSKn6wlShE1amL9 d9lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LtL2HZVK+P0c30MAByLL8r0VKNh+zbkLo486TTYNu+g=; b=hfbuWkf1ESQcWNzM7UtN3ylq/SbQnUYOMydabVUzwrSjZAAuxx6iIXMr/1hZgrKj0A 463+oox+oBlHUG6ZaWmo29oIUz5oROP+Yk7I9vDQSLK6dl6NpOWI6BRkZfdC14qrn6Iy S+O416IWP8biir8/MlY/R2pVd9NesD6VnjhxHA/gfgV6bQ2FpjvD3qiRXabP5o56Px/K Obdn38PoDYvaS/SeuQWuIf2/5ji6/YoadDHJkN3uspCOHlKs+d1m+dMaGYSyU+q9u8Og m6jbKSD/I/xCTu7Kyvs0Iwz0hGikTzy7Z55bXHGOoOpSBE6i2xKqNiJdNIDVvIh7u+wG edSg== X-Gm-Message-State: ANoB5pnkLVEGnrg9C6M0s+AgA1CFsU47Aw1NBXUkBGQTDFnZQX61ZFRe rFbCpgzNF2R+VHrT4TRO6P4= X-Google-Smtp-Source: AA0mqf4TGTvWfgxEPSZfs4RGCpC+rf0Br7Kx1H7Aii142ZmLCwU5k1xTOjgsNnMB8uHgkQE9j8GGBg== X-Received: by 2002:a17:906:7e4a:b0:78d:a136:732b with SMTP id z10-20020a1709067e4a00b0078da136732bmr11425814ejr.135.1668465020148; Mon, 14 Nov 2022 14:30:20 -0800 (PST) Received: from jernej-laptop.localnet (82-149-19-102.dynamic.telemach.net. [82.149.19.102]) by smtp.gmail.com with ESMTPSA id ky4-20020a170907778400b0077b523d309asm4668183ejc.185.2022.11.14.14.30.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Nov 2022 14:30:19 -0800 (PST) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: martin.botka1@gmail.com, Martin Botka Cc: ~postmarketos/upstreaming@lists.sr.ht, Konrad Dybcio , AngeloGioacchino Del Regno , Marijn Suijten , Jami Kettunen , Paul Bouchara , Jan Trmal , Tom , Martin Botka , 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 Subject: Re: [PATCH v3 2/2] arm64: dts: Add basic support for BIQU CB1 Date: Mon, 14 Nov 2022 23:30:17 +0100 Message-ID: <4534857.CvnuH1ECHv@jernej-laptop> In-Reply-To: <20221114214452.1993744-2-martin.botka@somainline.org> References: <20221114214452.1993744-1-martin.botka@somainline.org> <20221114214452.1993744-2-martin.botka@somainline.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221114_143031_293626_D115A883 X-CRM114-Status: GOOD ( 37.47 ) 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. 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. > 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) += sun50i-h6-pine-h64.dtb > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6-mini.dtb > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-biqu-cb1.dtb > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb > dtb-$(CONFIG_ARCH_SUNXI) += 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 = "BIQU CB1"; > + compatible = "biqu,cb1", "allwinner,sun50i-h616"; > + > + aliases { > + serial0 = &uart0; > + }; > + > + chosen { > + stdout-path = "serial0:115200n8"; > + }; > + > + leds { > + compatible = "gpio-leds"; > + > + led-0 { > + function = LED_FUNCTION_POWER; > + color = ; > + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12 */ > + default-state = "on"; > + }; > + > + led-1 { > + function = LED_FUNCTION_STATUS; > + color = ; > + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13 */ > + }; > + }; > + > + reg_vcc5v: regulator-vcc5v { > + /* board wide 5V supply directly from the USB-C socket */ > + compatible = "regulator-fixed"; > + regulator-name = "vcc-5v"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + regulator-always-on; > + }; > + > + reg_usb1_vbus: regulator-usb1-vbus { > + compatible = "regulator-fixed"; > + regulator-name = "usb1-vbus"; > + regulator-min-microvolt = <5000000>; > + regulator-max-microvolt = <5000000>; > + vin-supply = <®_vcc5v>; > + enable-active-high; > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */ > + }; > +}; > + > +&ehci1 { > + status = "okay"; > +}; > + > +&ehci2 { > + status = "okay"; > +}; > + > +&ehci3 { > + status = "okay"; > +}; > + > +&mmc0 { > + vmmc-supply = <®_dldo1>; > + cd-gpios = <&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 = <4>; > + status = "disabled"; Why is set to disabled? If it's not a typo, remove whole node. It could be added later when it works. > +}; > + > +&ohci1 { > + status = "okay"; > +}; > + > +&ohci2 { > + status = "okay"; > +}; > + > +&ohci3 { > + status = "okay"; > +}; > + > +&r_i2c { > + status = "okay"; > + > + axp1530: pmic@36 { > + compatible = "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. > + reg = <0x36>; > + wakeup-source; > + > + regulators{ > + reg_dcdc1: dcdc1 { > + regulator-name = "axp1530-dcdc1"; > + regulator-min-microvolt = <500000>; > + regulator-max-microvolt = <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 = <25>; > + regulator-final-delay-us = <50>; > + regulator-always-on; > + }; > + > + reg_dcdc2: dcdc2 { > + regulator-name = "axp1530-dcdc2"; > + regulator-min-microvolt = <500000>; > + regulator-max-microvolt = <1540000>; This one is most likely used by GPU. Its range must also be adjusted to GPU needs. > + regulator-step-delay-us = <25>; > + regulator-final-delay-us = <50>; > + regulator-ramp-delay = <200>; > + regulator-always-on; > + }; > + > + reg_dcdc3: dcdc3 { > + regulator-name = "axp1530-dcdc3"; > + regulator-min-microvolt = <500000>; > + regulator-max-microvolt = <1840000>; This one looks like it supplies DRAM. You should set both min and max to actual DRAM needs. > + regulator-step-delay-us = <25>; > + regulator-final-delay-us = <50>; > + regulator-always-on; > + }; > + > + reg_aldo1: ldo1 { ldo1 -> aldo1 > + regulator-name = "axp1530-aldo1"; > + regulator-min-microvolt = <1800000>; > + regulator-max-microvolt = <1800000>; > + regulator-step-delay-us = <25>; > + regulator-final-delay-us = <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 Best regards, Jernej > + regulator-name = "axp1530-dldo1"; > + regulator-min-microvolt = <3300000>; > + regulator-max-microvolt = <3300000>; > + regulator-step-delay-us = <25>; > + regulator-final-delay-us = <50>; > + regulator-always-on; > + }; > + }; > + }; > +}; > + > +&uart0 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_ph_pins>; > + status = "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 = "peripheral"; > + status = "okay"; > +}; > + > +&usbphy { > + usb1_vbus-supply = <®_usb1_vbus>; > + status = "okay"; > +}; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel