From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (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 5F40E664B4 for ; Tue, 20 Feb 2024 11:16:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708427785; cv=none; b=pSmRGii6gnmhpMSEd/yRlwCS2ifpkZJv1ZUsuKVtLh9KLqRF/DrpAZ5QedFTDz6zWksEb0XaZldH6s36/yZ1jqiE9fCvcDEADIIAHnqsibzzO4h6gnNSeagy86Ai7ZyUg8lY3O0lb2GcLIj6zYADfRdmW8AXLvQsxiIcpx5+4G4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708427785; c=relaxed/simple; bh=0XEVX7reUloJJ0HXCmKNanytjESGdOW7twiOSY0z6jI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lOLkw6HtGMebscwzl+/1lDWqTrfcV+el+eHy/er/MeqaKW7qb8Eff318YHVyOoO4TxFxtYF6tVOvVoiihIa7ltDlHiwl7FDvBT8ivg8mNAFQYYf+HtUvR4ICMjQGdr8LaZRt3HhzYOPx6Q8JWIwuchlg4uBHOhYUGJM4M8eTsl0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=bgdev.pl; spf=none smtp.mailfrom=bgdev.pl; dkim=pass (2048-bit key) header.d=bgdev-pl.20230601.gappssmtp.com header.i=@bgdev-pl.20230601.gappssmtp.com header.b=iDGtm6aD; arc=none smtp.client-ip=209.85.222.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=bgdev.pl Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bgdev.pl Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bgdev-pl.20230601.gappssmtp.com header.i=@bgdev-pl.20230601.gappssmtp.com header.b="iDGtm6aD" Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-7d6a85586e3so2513118241.2 for ; Tue, 20 Feb 2024 03:16:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20230601.gappssmtp.com; s=20230601; t=1708427782; x=1709032582; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=/TGQQf9QVaNxe+P/ET43bTj+OwzYLCPf9zjW80RckT8=; b=iDGtm6aDQFMcDmVljb+fXB1UkYRGIUzBmDrTWX9JQOVFyeXsgoLl4wS9utqR9RV71f T+8WHTK/iwqEgTvdFhQudDhLfT4UzAX9vI/v8NGmdEsUnUPLq2PxHkN3IvBa2OGOPVGy LLNkNuWZEubob9k5MyrOgCf2GRn6NzxhmvgqGcfhyV5jQlXdpXjJroxrzwveUbhdM2Ay otnH9ivwaAR4c8tL84tYyfYHWLmNTDYIFluzKDDitHIJ8viijOpjl5JUOLopdC4YTshI RfL7ZXx7mldMdMT3nwydmjVrhK0J1aVXrd/e25JWwSUdFclB4zHERRvw/ru6KwedJ/Ig scfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708427782; x=1709032582; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=/TGQQf9QVaNxe+P/ET43bTj+OwzYLCPf9zjW80RckT8=; b=awc1YAu42kcHKxnBnhaXO4EJ/Ngp/PjGIYlX0i24/s/XUF9hwEzcbpXRsEBrjmsnZO LZKneWfV4rO2MVrUm6f0et9+WYjQb6COfoNflxdtwPZJgKwCgUteVcLP+wFWmlb2Qwpx B68SN7ap5kyvZ8gw0UqC/XmgZ5gF91/h6Ylq7obVSPK2Rrf2n+xxN5HLdxu6ct3B2L2J pISOkYhJYkmZ+bC7cmjRwn0wnTh1ZEDFS7EXOMusZFYMupMJGol8W5NDxaxCID4mEeM+ KsVAjhMldmn5+qAGUCxsqHHNAmNlDP+jn9DQnkBnlu5FYQwaRgmdLgwLn8k0VbSXdEHl AvEQ== X-Forwarded-Encrypted: i=1; AJvYcCUmBXPHpLICBueFKa+8iiEFeXcWPe/gSswCL+PzmL8brruS7JM4tEuNgSbqhV9k/+aKDEtXd45XdLr7wKfgHjusBto5MxiK/ct51g== X-Gm-Message-State: AOJu0YyzSlMI3x6D5W44MYw44+6OHcHxFAwQZVC/+Mo4Gnp3hZCUDbgQ 0FW2mm40gHRdW5ky7ASOFZT6T8P95X6lDfWFjDx6pzREgU2REvZHtEF1LKeJzzXKZ/l6zvTVpi/ K0PvA8yd5b/tVn/sn4DLq88xtcDvppZ5zjKXxww== X-Google-Smtp-Source: AGHT+IF0CN7Ryol7qmamq7DrWXyYZkwvZgbPRNHrR3nczqiDKiEYYS7aZK8HtFSbIhrDgqTa7oMs3VHOgqV6taESy9U= X-Received: by 2002:a05:6102:1610:b0:470:51ab:3e46 with SMTP id cu16-20020a056102161000b0047051ab3e46mr5334654vsb.30.1708427781847; Tue, 20 Feb 2024 03:16:21 -0800 (PST) Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240216203215.40870-1-brgl@bgdev.pl> <20240216203215.40870-10-brgl@bgdev.pl> <48164f18-34d0-4053-a416-2bb63aaae74b@sirena.org.uk> <8e392aed-b5f7-486b-b5c0-5568e13796ec@sirena.org.uk> In-Reply-To: <8e392aed-b5f7-486b-b5c0-5568e13796ec@sirena.org.uk> From: Bartosz Golaszewski Date: Tue, 20 Feb 2024 12:16:10 +0100 Message-ID: Subject: Re: [PATCH v5 09/18] arm64: dts: qcom: qrb5165-rb5: model the PMU of the QCA6391 To: Mark Brown Cc: Marcel Holtmann , Luiz Augusto von Dentz , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Kalle Valo , Bjorn Andersson , Konrad Dybcio , Liam Girdwood , Catalin Marinas , Will Deacon , Bjorn Helgaas , Saravana Kannan , Geert Uytterhoeven , Arnd Bergmann , Neil Armstrong , Marek Szyprowski , Alex Elder , Srini Kandagatla , Greg Kroah-Hartman , Abel Vesa , Manivannan Sadhasivam , Lukas Wunner , Dmitry Baryshkov , linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org, linux-pm@vger.kernel.org, Bartosz Golaszewski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 19, 2024 at 8:59=E2=80=AFPM Mark Brown wro= te: > > On Mon, Feb 19, 2024 at 07:48:20PM +0100, Bartosz Golaszewski wrote: > > On Mon, Feb 19, 2024 at 7:03=E2=80=AFPM Mark Brown = wrote: > > > On Fri, Feb 16, 2024 at 09:32:06PM +0100, Bartosz Golaszewski wrote: > > > > > + vreg_pmu_aon_0p59: ldo1 { > > > > + regulator-name =3D "vreg_pmu_aon_0p59= "; > > > > + regulator-min-microvolt =3D <540000>; > > > > + regulator-max-microvolt =3D <840000>; > > > > + }; > > > > That's a *very* wide voltage range for a supply that's got a name end= ing Because it's an error, it should have been 640000. Thanks for spotting it. > > > in _0_p59 which sounds a lot like it should be fixed at 0.59V. > > > Similarly for a bunch of the other supplies, and I'm not seeing any > > > evidence that the consumers do any voltage changes here? There doesn= 't > > > appear to be any logic here, I'm not convinced these are validated or > > > safe constraints. > > > No, the users don't request any regulators (or rather: software > > representations thereof) because - as per the cover letter - no > > regulators are created by the PMU driver. This is what is physically > > on the board - as the schematics and the datasheet define it. I took > > The above makes no sense. How can constraints be "what is physically on > the board", particularly variable constrants when there isn't even a > consumer? What values are you taking from which documentation? > The operating conditions for PMU outputs. I took them from a confidential datasheet. There's a table for input constraints and possible output values. And what do you mean by there not being any consumers? The WLAN and BT *are* the consumers. > The cover letter and binding both claimed (buried after large amounts of > changelog) that these PMUs were exposing regulators to consumers and the > DTS puports to do exactly that... > Yes, but I'm not sure what the question is. > > the values from the docs verbatim. In C, we create a power sequencing > > provider which doesn't use the regulator framework at all. > > For something that doesn't use the regulator framework at all what > appears to be a provider in patch 16 ("power: pwrseq: add a driver for > the QCA6390 PMU module") seems to have a lot of regualtor API calls? This driver is a power sequencing *provider* but also a regulator *consumer*. It gets regulators from the host and exposes a power sequencer to *its* consumers (WLAN and BT). On DT it exposes regulators (LDO outputs of the PMU) but we don't instantiate them in C. Bart