From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f42.google.com (mail-ed1-f42.google.com [209.85.208.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA8D529DB96 for ; Fri, 27 Jun 2025 11:33:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751024042; cv=none; b=YunvNFK7m/Qp4qpNJQZuJmrz9TfXFoXd6sX4qnpSM7HkOPm4Ng5pyNuw6QqB8dg7T7I43iOjeYrEX9y1833DYsGVpD3mYpcPF0+JOQneY8ectixflGHwfiaTumytZjAUhv4+37TbL3rWpLvSPzkc5DQxpzqlBUxrzrAt7JV6Abg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751024042; c=relaxed/simple; bh=nrg/5Cr/Ct/L2mrn4jAnolMDR4V2365AXYCSvZSKjPs=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Szgy0LbpiSNwj2/givm2KRodXKpf3AoziSDMV3E9IEhJSYPBVkg+fAQa0rTAcWcO6AFofk2zpMOC+kVQB75wVgCQlr5F81GwH/NfAj6foQ2sqi3mTDmMzPqj0isOcR8FseKejT/jbpddMl20Co60B3bZftfkg61V3swZ06D6IzQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fairphone.com; spf=pass smtp.mailfrom=fairphone.com; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b=m65ozer2; arc=none smtp.client-ip=209.85.208.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=fairphone.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fairphone.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fairphone.com header.i=@fairphone.com header.b="m65ozer2" Received: by mail-ed1-f42.google.com with SMTP id 4fb4d7f45d1cf-60c93c23b08so678349a12.3 for ; Fri, 27 Jun 2025 04:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fairphone.com; s=fair; t=1751024038; x=1751628838; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8TQIk1vNThf+KbhPSV308tydy65v8ZFP99g2fX+hJzE=; b=m65ozer2x2+YrV6OGSlVtJtLgt3AN5unm8zC2OlARa+S5ZKLL3S0PNEJQhU8PrsbfP TBMJonQayyP0LxMWECp2zT4KNGaHy3mdGnYpuVwrLeaKok4AlEoH4CtWgLr+xnJrgpZ9 qOZEZ7pfq0WO8ZuUBwI82SphF0OGKJd+qDG02c+Wf++qW+nwDHeFYdVOWO4DAx4GW4cT NbAk+13orgzXztKq8gEkXb1i1o59oksbsfWDsiO0H9+kKKgLNfLoUCh1fPA/1WcMlEte 79k4s3F5a19N+8FYmUdL3Mfvg85txlmbTMh2EjJ07PNjqOSVY5w1whI1uQUjx93Prgtu xJTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751024038; x=1751628838; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=8TQIk1vNThf+KbhPSV308tydy65v8ZFP99g2fX+hJzE=; b=Ms7CGc+LYOi8YRbWm/YGDn4f0wNvfw6y8qLqtP9gc32hUEiAqPKENaW+1ITUsBeNjO U+BBrOQg5vZ3Qh1RlH5ElJ+Smn7/JkrNJnDVKSjdxNJwda9nv6m97VyN7OwXZ6RI1I7g cavHo9kQaIrB6uAilYM2jyTw6aE/OPHvvEJnd6b2fMnqua6LfSTy7A994s71eStaXX+K tR8phvq+gYfD+pNg12bi8IB3CVvTGyysmFohBXrB8BOm4cpKkB7iaooUIa82Rg+biTPy HEVy/DHugkPFzy7dFM9DFfx6lLLdan7/F15qzX01XDxJwHkQipebqhCI9kCUOSmYCmNf 8WsA== X-Forwarded-Encrypted: i=1; AJvYcCXT4r30LRgwK0i4XsmPnyNJ4onGQtDR7U50C5J98lUqJGPpt++Fx1u6+4ne+7At2QAn27fUBDrgKhhHDJA=@vger.kernel.org X-Gm-Message-State: AOJu0Yxn6L4/1VVLT2GUBiso4wx0013Mxr4+5nq2ZIixt9bnRpFjB54s zjN7MbgI0K9z6Mo+w4nw2++GIWkoNyMMebX28i+or4Pj1hgTaXJaAT3Ok/xoS9k1htA= X-Gm-Gg: ASbGncv0tpl3tXkHJ6moNahQHSvWO4JlEnOQMW41swpst6c5UFNoc240eo2PYgfJE6i nRkTUilEeOlo8lCORP0mYr0bBcMOiaQDNtoLmsfC/gGZfRYNa7pFAubmIqfh7DYZCbwn8huL5ML YVNQcktIPciZi4L8EaJ6DEKYMhjDubiOw0GC9l8J/uuhzbRsgO6qtS+b2MOPycmVk+blpg+iNpH QIvlkzkE8NtMh5Q/vmn/AEJ6UiRaVMmRq8q08nbnW5rgDVLgeygEa4/0x5Z8UqdqmabhsVI+KMa +eqlJifb1wJIZpoPJDG1Nj+TY/qemerL37sR2HXVSP390mVSkLoacRH2U6SQn43586Bifjh3F4C c0k5tT9D7N1o2qeO1TS79EXyseFJMmNw= X-Google-Smtp-Source: AGHT+IFTB4ZISQsWRjBnTltqxZ+EzRDnHXDtrROSz2QQZgqYVC+7zZ8R4yhdcBmhaWSRI1bSl9PUhg== X-Received: by 2002:a17:906:7951:b0:ad8:a935:b905 with SMTP id a640c23a62f3a-ae34fddeae3mr245758066b.22.1751024037927; Fri, 27 Jun 2025 04:33:57 -0700 (PDT) Received: from localhost (144-178-202-138.static.ef-service.nl. [144.178.202.138]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ae353c6bdafsm108070066b.143.2025.06.27.04.33.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Jun 2025 04:33:57 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 27 Jun 2025 13:33:56 +0200 Message-Id: Cc: <~postmarketos/upstreaming@lists.sr.ht>, , , , , , , , , , Subject: Re: [PATCH 14/14] arm64: dts: qcom: Add The Fairphone (Gen. 6) From: "Luca Weiss" To: "Konrad Dybcio" , "Will Deacon" , "Robin Murphy" , "Joerg Roedel" , "Rob Herring" , "Krzysztof Kozlowski" , "Conor Dooley" , "Rafael J. Wysocki" , "Viresh Kumar" , "Manivannan Sadhasivam" , "Herbert Xu" , "David S. Miller" , "Vinod Koul" , "Bjorn Andersson" , "Konrad Dybcio" , "Robert Marko" , "Das Srinagesh" , "Thomas Gleixner" , "Jassi Brar" , "Amit Kucheria" , "Thara Gopinath" , "Daniel Lezcano" , "Zhang Rui" , "Lukasz Luba" , "Ulf Hansson" X-Mailer: aerc 0.20.1-0-g2ecb8770224a-dirty References: <20250625-sm7635-fp6-initial-v1-0-d9cd322eac1b@fairphone.com> <20250625-sm7635-fp6-initial-v1-14-d9cd322eac1b@fairphone.com> <4200b3b8-5669-4d5a-a509-d23f921b0449@oss.qualcomm.com> In-Reply-To: <4200b3b8-5669-4d5a-a509-d23f921b0449@oss.qualcomm.com> On Wed Jun 25, 2025 at 4:38 PM CEST, Konrad Dybcio wrote: > On 6/25/25 11:23 AM, Luca Weiss wrote: >> Add a devicetree for The Fairphone (Gen. 6) smartphone, which is based >> on the SM7635 SoC. > > [...] > >> + /* Dummy panel for simple-framebuffer dimension info */ >> + panel: panel { >> + compatible =3D "boe,bj631jhm-t71-d900"; >> + width-mm =3D <65>; >> + height-mm =3D <146>; >> + }; > > I haven't ran through all the prerequisite-xx-id, but have > you submitted a binding for this? Actually not, kind of forgot about this. I believe I can create a (mostly?) complete binding for the panel, but this simple description for only width-mm & height-mm will differ from the final one, which will have the DSI port, pinctrl, reset-gpios and various supplies. I think I'll just drop it from v2 and keep it locally only, to get the simpledrm scaling right. > > [...] > >> + reserved-memory { >> + /* >> + * ABL is powering down display and controller if this node is >> + * not named exactly "splash_region". >> + */ >> + splash_region@e3940000 { >> + reg =3D <0x0 0xe3940000 0x0 0x2b00000>; >> + no-map; >> + }; >> + }; > > :/ maybe we can convince ABL not to do it.. Yes, we talked about that. I will look into getting "splash-region" and "splash" also into the ABL (edk2) build for the phone. Still won't resolve that for any other brand of devices. > > [...] > >> + vreg_l12b: ldo12 { >> + regulator-name =3D "vreg_l12b"; >> + /* >> + * Skip voltage voting for UFS VCC. >> + */ > > Why so? >From downstream: /* * This is for UFS Peripheral,which supports 2 variants * UFS 3.1 ,and UFS 2.2 both require different voltages. * Hence preventing voltage voting as per previous targets. */ I haven't (successfully) brought up UFS yet, so I haven't looked more into that. The storage on FP6 is UFS 3.1 though fwiw. > > [...] > >> +&gpi_dma0 { >> + status =3D "okay"; >> +}; >> + >> +&gpi_dma1 { >> + status =3D "okay"; >> +}; > > These can be enabled in SoC DTSI.. it's possible that the secure=20 > configuration forbids access to one, but these are generally made > per-platform Ack > > [...] > >> +&pm8550vs_d { >> + status =3D "disabled"; >> +}; >> + >> +&pm8550vs_e { >> + status =3D "disabled"; >> +}; >> + >> +&pm8550vs_g { >> + status =3D "disabled"; >> +}; > > Hm... perhaps we should disable these by deafult Do you want me to do this in this patchset, or we clean this up later at some point? I'd prefer not adding even more dependencies to my patch collection right now. > > [...] > >> +&pmr735b_gpios { >> + pm8008_reset_n_default: pm8008-reset-n-default-state { >> + pins =3D "gpio3"; >> + function =3D PMIC_GPIO_FUNC_NORMAL; >> + bias-pull-down; >> + }; >> + >> + s1j_enable_default: s1j-enable-default-state { >> + pins =3D "gpio1"; >> + function =3D PMIC_GPIO_FUNC_NORMAL; >> + power-source =3D <0>; >> + bias-disable; >> + output-low; >> + }; > > ordering by pin ID makes more sense, here and in tlmm > > (and is actually written down) > https://docs.kernel.org/devicetree/bindings/dts-coding-style.html#order-o= f-nodes Ah, that's news to me. Thanks! > > [...] > >> +&pon_resin { >> + linux,code =3D ; >> + status =3D "okay"; > > \n before status consistently, please Ack > > [...] > >> +&tlmm { >> + /* >> + * 8-11: Fingerprint SPI >> + * 13: NC >> + * 63-64: WLAN UART >> + */ >> + gpio-reserved-ranges =3D <8 4>, <13 1>, <63 2>; > > Please match the style in x1-crd.dtsi Ack > > [...] > >> +&usb_1 { >> + dr_mode =3D "otg"; >> + >> + /* USB 2.0 only */ > > Because there's no usb3phy description yet, or due to hw design? HW design. Funnily enough with clk_ignore_unused this property is not needed, and USB(2.0) works fine then. Just when (I assume) the USB3 clock is turned off which the bootloader has enabled, USB stops working. Regards Luca > > Konrad