Message ID | 20240214121614.2723085-1-bryan.odonoghue@linaro.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:bc8a:b0:106:860b:bbdd with SMTP id dn10csp1168237dyb; Wed, 14 Feb 2024 04:16:37 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCU7yRHhtCiazR8CarFyqOCNXkVJ9HeMLiFOjZBQ/W4JXWIzyAQTj7iwMpGZSpLMlbzbJ4G7oTAnh1/TZzQvRMoHDyfTjA== X-Google-Smtp-Source: AGHT+IFUMPhQvs1iLBwURZDJYWr4wMoicLn3i/EWVwSA61YChS8vE2QqIWz++hojzxphu7NipBEs X-Received: by 2002:a17:903:2287:b0:1db:4f26:1506 with SMTP id b7-20020a170903228700b001db4f261506mr3547930plh.35.1707912996783; Wed, 14 Feb 2024 04:16:36 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707912996; cv=pass; d=google.com; s=arc-20160816; b=qVoZdXCEtHXO7IngyP7tL6Fbm9WseYDg28JHc4TfNSL1FGZ7dTuw7zBQRw8VeGHnnG SEsy84z/C9SCj4D2DH1zIYUmHJTKJjB+aRp2z63fHfC+6VTTjFS37ypHVxj3P/BZe60O woCk+vNAhGJEytY5JHjfgj7pbkS4NQWYqwZd/McaU8jjxpF2GSrIlNzab3SSZJhE/YpW kwOxzIx/ixigs1Oz5JcN1o52MHPRo4GJ2ls6Bksinmwihi0kQAVfaHlObjKYR8q/mFqE 9iJ0+NLBnv4g4mTLL19cmhyIJvdzedhefbQWm7lf+7ASdlDoiIgp/QGUoKKvw6Ry9xL2 1x/g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=GhHuiCAcyptrdbLMF5Odf/hTRL9Avb+7UyPysoDXBIg=; fh=fBV8Djw1fzKfQWEVgybJTrBCnnL/cyTvGclv3zhcp3s=; b=mP0O83T0bsSYgRdufBUMAiMq0md3y5ymazUE/CfgVrrJlCK5WBj90ZM++FO3GqfH7s WG8kZxQvrHn0eHyQDe6Kg1IN7dRzYmkZ0/Kk7Dxtg/xrbEoNKCAtivstde/hDGyoc/JK nagMZHg+dW2LAUew1WvpFU2i4vVHqW69xVXsGqFmBajnMqXGJyNrKR2v6Ax3clib6waE tw32DprzjeKjXvTanLwNnhKoledwwa8t8aKyK4uVdNjuJMVteerV6/DJvBp6CmfmcDBt gRL4LKLG4cm9AXZV2y8pGAKGi4kjWgj7jfYh0tivCGtawyNLuSXR0yP9CeqNLNOrp2Nx Rfqw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=o2SmQ6Uj; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org X-Forwarded-Encrypted: i=2; AJvYcCVNkjQDTgbcltGdUexewNJWkAdKRpKy5HmRms738aXK7d9Oj6o+fMLGgs0XScDd60wlGTkO0VXXBhtMDZKUnK1pWT7lSg== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id p16-20020a1709027ed000b001db535f1530si1422365plb.419.2024.02.14.04.16.36 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 04:16:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=o2SmQ6Uj; arc=pass (i=1 spf=pass spfdomain=linaro.org dkim=pass dkdomain=linaro.org dmarc=pass fromdomain=linaro.org); spf=pass (google.com: domain of linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-65181-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 8A51528A510 for <ouuuleilei@gmail.com>; Wed, 14 Feb 2024 12:16:36 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7640B1BC4A; Wed, 14 Feb 2024 12:16:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="o2SmQ6Uj" Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 26F1F1AAD9 for <linux-kernel@vger.kernel.org>; Wed, 14 Feb 2024 12:16:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707912980; cv=none; b=Z6JD24WgMbpU1q3CuqcsuDujUNsQ20i/KnFExS2kO+esyN9od3DWVSctUL20SFrRIsOV8C8MgAyyw22E5QpUyhzakjQAc9Xo39H+OzARGoVvb//Nt+oBkF9/A+8/8X4FQvsEUAYjyIbel/Vq2qFNzfY4tHrf8BOItIf1iZOyoE4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707912980; c=relaxed/simple; bh=P4QhJcesqbYNm9nO2fZ1EuiQnbIfQyGBttkwBRDMqKk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=mhxy1TNLNu8vRRNjh0GYkbJLrRJtgWVYttZ0RR4FvFKjBsUbbaj2VvLC9nhbFp0HQscw9onwRcAnKF8UOmTfDhVdQ8LkFvLXZRl9+cu3oJNzy8ciJTECVZFmapvTacarpq75a3USWkdcD2bONuY5Bedm2/qnkXset9nibQF9G2w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=o2SmQ6Uj; arc=none smtp.client-ip=209.85.221.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-33cec911a31so269367f8f.1 for <linux-kernel@vger.kernel.org>; Wed, 14 Feb 2024 04:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1707912977; x=1708517777; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=GhHuiCAcyptrdbLMF5Odf/hTRL9Avb+7UyPysoDXBIg=; b=o2SmQ6Uj/Il3isavHk6kGghuiOGxm8oTJBnpDSNtAfh9l3BoQuw4+UnlVsuyAQ6NbP htg3yb3pktmP+0+H8UY0xWZWjEQjjgjqTGXN7nB2Q+ZmihAVpwdintDupK2vlZQJ1Kp0 n2YHvjyQZXMsyGA8bk5LvzDtD58pzCV0+Im1tvulfhp0mHv6z1yLYJj2/VzHHrIjJm98 yEWeb7KZGqXpaX59yfBepxlPoFWktbaOqaQf00J0ZOMqbhS6ioEoys86IIQhavMSj9j/ PSJPY/68yH2j1+QmzeZvkxMTvcQg0+IMSWjJjJzKUAjjhVvksAW8LnbouoWPg0PKXAwT 9cLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707912977; x=1708517777; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=GhHuiCAcyptrdbLMF5Odf/hTRL9Avb+7UyPysoDXBIg=; b=cRRnhOZ8AbiW1I/oHEXlIsDgCNU1nraQOXAsMs4hosLJuPHq/NUQkFyzCmMh8oZ8CO N2ljnBcismOe50WjRAxrqigHWY2oIsMf1qHFw4EYK9KZ3qODe0dYXGdGbqXtLBBBEr6z ZC7UzD6Z1fcHvrzSmwVgm8aGWJW0hWFIZ3WykR4MK2iV4d6Vor5Bqb7u9Hf/q6p9reOT /DD27yArAB5uwLc9srTOeHI5eFv4KTGF61yV+8sz/QaJnTR2yOwziCdxfvJ/5lzC049C 1bItp1lnq2C7UfXw1dRmZulnX0sCFWIOg63ChKR1WhidTarLePnad2e7KRw41hxzGqFy dvuw== X-Forwarded-Encrypted: i=1; AJvYcCXfryAZ85ScdlNoKviqkSVPEzyFAGvi2YdSormesihJvUSGyW12Oa84EPFW/NQrIattIX2h+BGQ0ezfuk2/jjeUy0Tgk0YbCJbTzdtw X-Gm-Message-State: AOJu0Yy23/XudLPRyiG1opjTteeHjYjESu8btvqJvJI2SJf1CimHLrGN te95cXGpGc9u0T886hT1GoZ6Djl1BYVlxTsEqm7RXY7kcs94w4goc16sYpHNRNw= X-Received: by 2002:a5d:618b:0:b0:33b:87c1:c51 with SMTP id j11-20020a5d618b000000b0033b87c10c51mr1616668wru.17.1707912977343; Wed, 14 Feb 2024 04:16:17 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXz/1HEPbuSKpdtkHcO2L0svgXhaeUDI1M+OwwgkRZs7ANreAgQ4dGQdI9AzQ7tkZOiGk9cahz3I4l+81PMEFtQliPZlAtXCnyEsrHOqKTRsGMaAxQk7WADa1YOSACvPeCYpJ3ZNq/0DuD7+Fwj3v8XVXFINRbV6VFmnqpnbJzLyCewIgTd0zAkn5f9E4B8pYvO/Qo4mSO+Ciaum4OXN+Axco9enKhIz7/hm5VS2+5KDPXrHN7DMYpH4qF0XYOwb0hgcJE/kC6oowBSTRWsHVsoRAiMNCBgJaHfGovO8w04aLe3D4EOeyvz/jZcA4X12PC7t673ysC2 Received: from sagittarius-a.nxsw.local ([176.61.106.68]) by smtp.gmail.com with ESMTPSA id g7-20020a5d5407000000b003392206c808sm12195824wrv.105.2024.02.14.04.16.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 04:16:16 -0800 (PST) From: Bryan O'Donoghue <bryan.odonoghue@linaro.org> To: bryan.odonoghue@nexus-software.ie, andersson@kernel.org, konrad.dybcio@linaro.org, lgirdwood@gmail.com, broonie@kernel.org, quic_fenglinw@quicinc.com, quic_collinsd@quicinc.com Cc: linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, bryan.odonoghue@linaro.org Subject: [PATCH] regulator: qcom-rpmh: Fix pm8010 pmic5_pldo502ln minimum voltage Date: Wed, 14 Feb 2024 12:16:14 +0000 Message-ID: <20240214121614.2723085-1-bryan.odonoghue@linaro.org> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790876578066264547 X-GMAIL-MSGID: 1790876578066264547 |
Series |
regulator: qcom-rpmh: Fix pm8010 pmic5_pldo502ln minimum voltage
|
|
Commit Message
Bryan O'Donoghue
Feb. 14, 2024, 12:16 p.m. UTC
The relevant documents and the dtsi specify the minimum value at 1.808v not
1.8v.
Prior to this fix we get the following error on boot:
[ 1.353540] vrej_l3m_1p8: failed to get the current voltage: -ENOTRECOVERABLE
[ 1.353544] qcom-rpmh-regulator 17500000.rsc:regulators-9: ldo3: devm_regulator_register() failed, ret=-131
[ 1.353546] qcom-rpmh-regulator: probe of 17500000.rsc:regulators-9 failed with error -131
Fixes: 2544631faa7f ("regulator: qcom-rpmh: add support for pm8010 regulators")
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
drivers/regulator/qcom-rpmh-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 24-02-14 12:16:14, Bryan O'Donoghue wrote: > The relevant documents and the dtsi specify the minimum value at 1.808v not > 1.8v. > > Prior to this fix we get the following error on boot: > [ 1.353540] vrej_l3m_1p8: failed to get the current voltage: -ENOTRECOVERABLE > [ 1.353544] qcom-rpmh-regulator 17500000.rsc:regulators-9: ldo3: devm_regulator_register() failed, ret=-131 > [ 1.353546] qcom-rpmh-regulator: probe of 17500000.rsc:regulators-9 failed with error -131 > > Fixes: 2544631faa7f ("regulator: qcom-rpmh: add support for pm8010 regulators") > Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> > --- > drivers/regulator/qcom-rpmh-regulator.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c > index 80e304711345b..767a17fe0d51b 100644 > --- a/drivers/regulator/qcom-rpmh-regulator.c > +++ b/drivers/regulator/qcom-rpmh-regulator.c > @@ -757,7 +757,7 @@ static const struct rpmh_vreg_hw_data pmic5_pldo502ln = { > .regulator_type = VRM, > .ops = &rpmh_regulator_vrm_ops, > .voltage_ranges = (struct linear_range[]) { > - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), > + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), > REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), > REGULATOR_LINEAR_RANGE(3104000, 29, 30, 96000), > REGULATOR_LINEAR_RANGE(3312000, 31, 31, 0), > -- > 2.43.0 > >
On Wed, Feb 14, 2024 at 12:16:14PM +0000, Bryan O'Donoghue wrote: > .voltage_ranges = (struct linear_range[]) { > - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), > + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), This will also offset all other voltages that get set, is that expected and desired?
On 14/02/2024 13:25, Mark Brown wrote: > On Wed, Feb 14, 2024 at 12:16:14PM +0000, Bryan O'Donoghue wrote: > >> .voltage_ranges = (struct linear_range[]) { >> - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), >> + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), > > This will also offset all other voltages that get set, is that expected > and desired? Yep, looks typo in the original submission. ldo3, ldo4 and ldo6 should all be 1.808. --- bod
On Wed, Feb 14, 2024 at 02:07:13PM +0000, Bryan O'Donoghue wrote: > On 14/02/2024 13:25, Mark Brown wrote: > > On Wed, Feb 14, 2024 at 12:16:14PM +0000, Bryan O'Donoghue wrote: > > > .voltage_ranges = (struct linear_range[]) { > > > - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), > > > + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), > > This will also offset all other voltages that get set, is that expected > > and desired? > Yep, looks typo in the original submission. > ldo3, ldo4 and ldo6 should all be 1.808. Not just that but also note that every voltage step in the range will have the 8mV offset added.
On 14/02/2024 14:13, Mark Brown wrote: > On Wed, Feb 14, 2024 at 02:07:13PM +0000, Bryan O'Donoghue wrote: >> On 14/02/2024 13:25, Mark Brown wrote: >>> On Wed, Feb 14, 2024 at 12:16:14PM +0000, Bryan O'Donoghue wrote: > >>>> .voltage_ranges = (struct linear_range[]) { >>>> - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), >>>> + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), > >>> This will also offset all other voltages that get set, is that expected >>> and desired? > >> Yep, looks typo in the original submission. > >> ldo3, ldo4 and ldo6 should all be 1.808. > > Not just that but also note that every voltage step in the range will > have the 8mV offset added. The documents I have just show sensors attached to ldo3, ldo4 and ldo6 fixed at 1.808. I don't think there's any better or different information than a +200000uV increment TBH. --- bod
On Wed, Feb 14, 2024 at 02:44:56PM +0000, Bryan O'Donoghue wrote: > On 14/02/2024 14:13, Mark Brown wrote: > > Not just that but also note that every voltage step in the range will > > have the 8mV offset added. > The documents I have just show sensors attached to ldo3, ldo4 and ldo6 fixed > at 1.808. > I don't think there's any better or different information than a +200000uV > increment TBH. This seems like a very surprising and unusual hardware design, the 1.808V voltage is already unusual. Note that this may break systems that are trying to set a range of say 1.8-2.0V if they actually need to set 2V.
On 14/02/2024 14:52, Mark Brown wrote: > On Wed, Feb 14, 2024 at 02:44:56PM +0000, Bryan O'Donoghue wrote: >> On 14/02/2024 14:13, Mark Brown wrote: > >>> Not just that but also note that every voltage step in the range will >>> have the 8mV offset added. > >> The documents I have just show sensors attached to ldo3, ldo4 and ldo6 fixed >> at 1.808. > >> I don't think there's any better or different information than a +200000uV >> increment TBH. > > This seems like a very surprising and unusual hardware design, the > 1.808V voltage is already unusual. Note that this may break systems > that are trying to set a range of say 1.8-2.0V if they actually need to > set 2V. Hmm. I'm sure the rail value should be 1.808 its all over the documentation for example when we get to index 3 we hit 2608000 REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), 1808000 0 2008000 1 2208000 2 2408000 x REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), And there are other rails @ 1v8 if 1v8 The one thing I can't easily verify is index 0 = 1808000 and not say 1800000 or indeed that the increment is 200000 and not say 8000. I'll see if I can ask around with the hw people and get a more complete answer. Similarly now that you've gotten me digging into this problem, it's not clear to me why this regulator isn't just a linear regulator with an 8mv increment over a range of indexes. At least the documentation I'm looking at doesn't elucidate. I'll dig some more. --- bod
On 14/02/2024 22:47, Bryan O'Donoghue wrote:
> And there are other rails @ 1v8 if 1v8
[sic] If 1v8 exact matters to you
On 2024/2/15 6:47, Bryan O'Donoghue wrote: > On 14/02/2024 14:52, Mark Brown wrote: >> On Wed, Feb 14, 2024 at 02:44:56PM +0000, Bryan O'Donoghue wrote: >>> On 14/02/2024 14:13, Mark Brown wrote: >> >>>> Not just that but also note that every voltage step in the range will >>>> have the 8mV offset added. >> >>> The documents I have just show sensors attached to ldo3, ldo4 and >>> ldo6 fixed >>> at 1.808. >> >>> I don't think there's any better or different information than a >>> +200000uV >>> increment TBH. >> >> This seems like a very surprising and unusual hardware design, the >> 1.808V voltage is already unusual. Note that this may break systems >> that are trying to set a range of say 1.8-2.0V if they actually need to >> set 2V. > > Hmm. I'm sure the rail value should be 1.808 its all over the > documentation for example when we get to index 3 we hit 2608000 > > REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), > 1808000 0 > 2008000 1 > 2208000 2 > 2408000 x > REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), > > And there are other rails @ 1v8 if 1v8 > > The one thing I can't easily verify is index 0 = 1808000 and not say > 1800000 or indeed that the increment is 200000 and not say 8000. > > I'll see if I can ask around with the hw people and get a more complete > answer. > > Similarly now that you've gotten me digging into this problem, it's not > clear to me why this regulator isn't just a linear regulator with an 8mv > increment over a range of indexes. > > At least the documentation I'm looking at doesn't elucidate. > > I'll dig some more. Please see the voltage steps for LDO3/4/6 described in the PM8010 TDOS document which is the most authoritative that we used internally for PMIC driver development: Index Vset (mV) 0 1800 1 2000 2 2200 3 2608 4 2624 5 2640 6 2656 7 2672 8 2688 9 2704 10 2720 11 2736 12 2752 13 2768 14 2784 15 2800 16 2816 17 2832 18 2848 19 2864 20 2880 21 2896 22 2912 23 2928 24 2944 25 2960 26 2976 27 2992 28 3008 29 3104 30 3200 31 3312 And I do see from the document change history that step 0 was changed from 1808mV and step 2 was changed from 2512mV, I don't know the reason of the change though. Fenglin > > --- > bod >
On 19/02/2024 3:06 a.m., Fenglin Wu wrote: > > > On 2024/2/15 6:47, Bryan O'Donoghue wrote: >> On 14/02/2024 14:52, Mark Brown wrote: >>> On Wed, Feb 14, 2024 at 02:44:56PM +0000, Bryan O'Donoghue wrote: >>>> On 14/02/2024 14:13, Mark Brown wrote: >>> >>>>> Not just that but also note that every voltage step in the range will >>>>> have the 8mV offset added. >>> >>>> The documents I have just show sensors attached to ldo3, ldo4 and >>>> ldo6 fixed >>>> at 1.808. >>> >>>> I don't think there's any better or different information than a >>>> +200000uV >>>> increment TBH. >>> >>> This seems like a very surprising and unusual hardware design, the >>> 1.808V voltage is already unusual. Note that this may break systems >>> that are trying to set a range of say 1.8-2.0V if they actually need to >>> set 2V. >> >> Hmm. I'm sure the rail value should be 1.808 its all over the >> documentation for example when we get to index 3 we hit 2608000 >> >> REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), >> 1808000 0 >> 2008000 1 >> 2208000 2 >> 2408000 x >> REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), >> >> And there are other rails @ 1v8 if 1v8 >> >> The one thing I can't easily verify is index 0 = 1808000 and not say >> 1800000 or indeed that the increment is 200000 and not say 8000. >> >> I'll see if I can ask around with the hw people and get a more >> complete answer. >> >> Similarly now that you've gotten me digging into this problem, it's >> not clear to me why this regulator isn't just a linear regulator with >> an 8mv increment over a range of indexes. >> >> At least the documentation I'm looking at doesn't elucidate. >> >> I'll dig some more. > Please see the voltage steps for LDO3/4/6 described in the PM8010 TDOS > document which is the most authoritative that we used internally for > PMIC driver development: I will look - however 1. The powertree internal docs for xe801000 show 1.808 rails derived from 1.856 rails for camera sensors 2. Publicly available with registration : 80-185821-1 https://docs.qualcomm.com/bundle/80-18582-1/resource/80-18582-1_REV_AV_PM8010_Data_Sheet.pdf Table 3-7 Linear/low-voltage regulator summary Specified programmable range (V) ldo3, ldo4, ldo6 = 1.808 to 3.312 3. The pmic ranges I'm looking at on the internal show increases of 8000 mv linearly > And I do see from the document change history that step 0 was changed > from 1808mV and step 2 was changed from 2512mV, I don't know the reason > of the change though. Hrmm... OK, that's enough to investigate further. --- bod
On 2/20/2024 4:20 PM, Bryan O'Donoghue wrote: > On 19/02/2024 3:06 a.m., Fenglin Wu wrote: >> >> >> On 2024/2/15 6:47, Bryan O'Donoghue wrote: >>> On 14/02/2024 14:52, Mark Brown wrote: >>>> On Wed, Feb 14, 2024 at 02:44:56PM +0000, Bryan O'Donoghue wrote: >>>>> On 14/02/2024 14:13, Mark Brown wrote: >>>> >>>>>> Not just that but also note that every voltage step in the range will >>>>>> have the 8mV offset added. >>>> >>>>> The documents I have just show sensors attached to ldo3, ldo4 and >>>>> ldo6 fixed >>>>> at 1.808. >>>> >>>>> I don't think there's any better or different information than a >>>>> +200000uV >>>>> increment TBH. >>>> >>>> This seems like a very surprising and unusual hardware design, the >>>> 1.808V voltage is already unusual. Note that this may break systems >>>> that are trying to set a range of say 1.8-2.0V if they actually need to >>>> set 2V. >>> >>> Hmm. I'm sure the rail value should be 1.808 its all over the >>> documentation for example when we get to index 3 we hit 2608000 >>> >>> REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), >>> 1808000 0 >>> 2008000 1 >>> 2208000 2 >>> 2408000 x >>> REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), >>> >>> And there are other rails @ 1v8 if 1v8 >>> >>> The one thing I can't easily verify is index 0 = 1808000 and not say >>> 1800000 or indeed that the increment is 200000 and not say 8000. >>> >>> I'll see if I can ask around with the hw people and get a more >>> complete answer. >>> >>> Similarly now that you've gotten me digging into this problem, it's >>> not clear to me why this regulator isn't just a linear regulator with >>> an 8mv increment over a range of indexes. >>> >>> At least the documentation I'm looking at doesn't elucidate. >>> >>> I'll dig some more. >> Please see the voltage steps for LDO3/4/6 described in the PM8010 TDOS >> document which is the most authoritative that we used internally for >> PMIC driver development: > > I will look - however > > 1. The powertree internal docs for xe801000 show 1.808 rails derived > from 1.856 rails for camera sensors > > 2. Publicly available with registration : 80-185821-1 > > https://docs.qualcomm.com/bundle/80-18582-1/resource/80-18582-1_REV_AV_PM8010_Data_Sheet.pdf > > Table 3-7 Linear/low-voltage regulator summary > > Specified programmable range (V) > ldo3, ldo4, ldo6 = 1.808 to 3.312 > > 3. The pmic ranges I'm looking at on the internal > show increases of 8000 mv linearly > >> And I do see from the document change history that step 0 was changed >> from 1808mV and step 2 was changed from 2512mV, I don't know the >> reason of the change though. > > Hrmm... > > OK, that's enough to investigate further. > Got feedback from the chip designer: "1.808V is the typical digital Vset logic output – always round up to the integer multiples of 8mV. However, 1.8V is a more commonly used output. So we made analog only change, move the tap point of the reference generator to 1.8V when it is programmed to 1.808V. If user program it to 1.8V, digital logic will round it up to 1.808V, send it to analog, then analog will map it to 1.8V. So the end result is the same regardless customer program it to 1.8V or 1.808V from PMIC register point of view. " So, programming it to either 1.8V or 1.808V, the HW will output 1.8V. I understand there is a problem for x1e801000 because its AOP side limits the voltage range to [1.808V, 1.808V] for LDO3/4/6 power rails, it won't work if linux side updates to use 1.8V. Actually the same issue applies to SM8550 and SM8650 if you simply update the voltage level to 1.808V, because their AOP side limits the voltage ranges for some of these LDOs to [1.8V, 1.8V]. One possible fix is just adding 1.808v as another level for these LDOs. Fenglin > --- > bod >
On 21/02/2024 9:11 a.m., Fenglin Wu wrote: > > So, programming it to either 1.8V or 1.808V, the HW will output 1.8V. I > understand there is a problem for x1e801000 because its AOP side limits > the voltage range to [1.808V, 1.808V] for LDO3/4/6 power rails, it won't > work if linux side updates to use 1.8V. Actually the same issue applies > to SM8550 and SM8650 if you simply update the voltage level to 1.808V, > because their AOP side limits the voltage ranges for some of these LDOs > to [1.8V, 1.8V]. Hmm. We have no use case for 1.808 to my knowledge - the sensors take voltages in the range 1.7 to 1.9 volts. TBH I think it should work just fine at 1.8v bang on. I'll test this theory on the reference hardware and repost either a patch or further discussion. But I think we should probably just leave what you've upstreamed and request 1.8 v in the dts honestly. Thanks --- bod
diff --git a/drivers/regulator/qcom-rpmh-regulator.c b/drivers/regulator/qcom-rpmh-regulator.c index 80e304711345b..767a17fe0d51b 100644 --- a/drivers/regulator/qcom-rpmh-regulator.c +++ b/drivers/regulator/qcom-rpmh-regulator.c @@ -757,7 +757,7 @@ static const struct rpmh_vreg_hw_data pmic5_pldo502ln = { .regulator_type = VRM, .ops = &rpmh_regulator_vrm_ops, .voltage_ranges = (struct linear_range[]) { - REGULATOR_LINEAR_RANGE(1800000, 0, 2, 200000), + REGULATOR_LINEAR_RANGE(1808000, 0, 2, 200000), REGULATOR_LINEAR_RANGE(2608000, 3, 28, 16000), REGULATOR_LINEAR_RANGE(3104000, 29, 30, 96000), REGULATOR_LINEAR_RANGE(3312000, 31, 31, 0),