Linux-Rockchip Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "jay.xu@rock-chips.com" <jay.xu@rock-chips.com>
To: "Heiko Stübner" <heiko@sntech.de>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	devicetree <devicetree@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Robin Murphy" <robin.murphy@arm.com>,
	杨凯 <kever.yang@rock-chips.com>
Cc: robh+dt <robh+dt@kernel.org>, cl <cl@rock-chips.com>,
	 "Peter Geis" <pgwipeout@gmail.com>,
	 "Sascha Hauer" <s.hauer@pengutronix.de>,
	 "xxm@rock-chips.com" <xxm@rock-chips.com>,
	 "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	 "Lee Jones" <lee.jones@linaro.org>,
	ulf.hansson <ulf.hansson@linaro.org>,
	 "Zhang Changzhong" <zhangchangzhong@huawei.com>,
	 "Tobias Schramm" <t.schramm@manjaro.org>,
	 "Johan Jonker" <jbx6244@gmail.com>
Subject: Re: Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support
Date: Fri, 6 Aug 2021 17:46:05 +0800	[thread overview]
Message-ID: <2021080617460178513151@rock-chips.com> (raw)
In-Reply-To: 3206032.SvYEEZNnvj@diego

Hi Heiko and Robin

--------------
jay.xu@rock-chips.com
>Hi Robin,
>
>Am Donnerstag, 5. August 2021, 18:27:36 CEST schrieb Robin Murphy:
>> On 2021-08-05 13:01, Michael Riesch wrote:
>> > From: Jianqun Xu <jay.xu@rock-chips.com>
>> >
>> > The io-domain registers on RK3568 SoCs have three separated bits to
>> > enable/disable the 1.8v/2.5v/3.3v power.
>> >
>> > This patch make the write to be a operation, allow rk3568 uses a private
>> > register set function.
>> >
>> > Since the 2.5v is not used on RK3568, so the driver only set
>>
>> FWIW, this seems at odds with what the first paragraph says - can anyone
>> clarify what exactly "not used" means here? Is it that the I/O domain
>> controller has been redesigned to support more than two logic levels on
>> the new generation of SoCs, but RK3568's I/O pads still only physically
>> support 1.8v and 3.3v; or is it that it *can* support 2.5v as well but
>> no currently-known RK3568-based designs use that?
>>
>> In the former case it's just a wording issue in the commit message, but
>> in the latter it's arguably worth implementing support now for the sake
>> of future compatibility.
>
>I hadn't looked that deeply into the rk356x io-domain config, but at least
>on a register level in the TRM it seems there are separate bits for
>"3.3V control", "2.5V control", "1.8V control" [0] for each io-domain.
>
>Of course the documentation is otherwise somewhat sparse.
>
>Maybe Jay or Kever [added] can explain a bit more about the 3 voltage
>levels.
>
>
>In general though, I tend to find the approach good enough for now.
>
>Especially as the io-domain stuff is always said to "can cause damage
>to the soc if used incorrectly" and it looks like nobody (including
>Rockchip) seems to have actual hardware using these 2.5V levels right now.
>
>So having code in there that no-one ever tested doesn't feel too good ;-)
> 
yes

about the 3bit

case     V33  V25  V18       result
0          0      0       0           IO safe, but cannot work
1          0      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
2          0      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
3          0      1       1           Invalid state, should avoid
4          1      0       0           IO require 3.3V, should < 3.63V, otherwise IO may damage
5          1      0       1           IO require 1.8V, should < 1.98V, otherwise IO may damage
6          1      1       0           IO require 2.5V, should < 2.75V, otherwise IO may damage
7          1      1       1           Invalid state, should avoid

>Adding this later when needed should be somewhat easy, as it really only
>needs adding of handling that 3rd control bit per domain.
>
>
>Heiko
>
>
>
>[0] what happens if none of the 3 is active? ;-)
>
>
>>
>> Robin.
>>
>> > 1.8v [enable] + 3.3v [disable] for 1.8v mode
>> > 1.8v [disable] + 3.3v [enable] for 3.3v mode
>> >
>> > There is not register order requirement which has been cleared by our IC
>> > team.
>> >
>> > Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
>> > ---
>> >   drivers/soc/rockchip/io-domain.c | 88 +++++++++++++++++++++++++++++---
>> >   1 file changed, 80 insertions(+), 8 deletions(-)
>> >
>> > diff --git a/drivers/soc/rockchip/io-domain.c b/drivers/soc/rockchip/io-domain.c
>> > index cf8182fc3642..13c446fd33a9 100644
>> > --- a/drivers/soc/rockchip/io-domain.c
>> > +++ b/drivers/soc/rockchip/io-domain.c
>> > @@ -51,13 +51,11 @@
>> >   #define RK3399_PMUGRF_CON0_VSEL	BIT(8)
>> >   #define RK3399_PMUGRF_VSEL_SUPPLY_NUM	9
>> >  
>> > -struct rockchip_iodomain;
>> > +#define RK3568_PMU_GRF_IO_VSEL0	(0x0140)
>> > +#define RK3568_PMU_GRF_IO_VSEL1	(0x0144)
>> > +#define RK3568_PMU_GRF_IO_VSEL2	(0x0148)
>> >  
>> > -struct rockchip_iodomain_soc_data {
>> > -	int grf_offset;
>> > -	const char *supply_names[MAX_SUPPLIES];
>> > -	void (*init)(struct rockchip_iodomain *iod);
>> > -};
>> > +struct rockchip_iodomain;
>> >  
>> >   struct rockchip_iodomain_supply {
>> >   struct rockchip_iodomain *iod;
>> > @@ -66,13 +64,62 @@ struct rockchip_iodomain_supply {
>> >   int idx;
>> >   };
>> >  
>> > +struct rockchip_iodomain_soc_data {
>> > +	int grf_offset;
>> > +	const char *supply_names[MAX_SUPPLIES];
>> > +	void (*init)(struct rockchip_iodomain *iod);
>> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> > +};
>> > +
>> >   struct rockchip_iodomain {
>> >   struct device *dev;
>> >   struct regmap *grf;
>> >   const struct rockchip_iodomain_soc_data *soc_data;
>> >   struct rockchip_iodomain_supply supplies[MAX_SUPPLIES];
>> > +	int (*write)(struct rockchip_iodomain_supply *supply, int uV);
>> >   };
>> >  
>> > +static int rk3568_iodomain_write(struct rockchip_iodomain_supply *supply, int uV)
>> > +{
>> > +	struct rockchip_iodomain *iod = supply->iod;
>> > +	u32 is_3v3 = uV > MAX_VOLTAGE_1_8;
>> > +	u32 val0, val1;
>> > +	int b;
>> > +
>> > +	switch (supply->idx) {
>> > +	case 0: /* pmuio1 */
>> > +	break;
>> > +	case 1: /* pmuio2 */
>> > +	b = supply->idx;
>> > +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> > +	b = supply->idx + 4;
>> > +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> > +
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val0);
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL2, val1);
>> > +	break;
>> > +	case 3: /* vccio2 */
>> > +	break;
>> > +	case 2: /* vccio1 */
>> > +	case 4: /* vccio3 */
>> > +	case 5: /* vccio4 */
>> > +	case 6: /* vccio5 */
>> > +	case 7: /* vccio6 */
>> > +	case 8: /* vccio7 */
>> > +	b = supply->idx - 1;
>> > +	val0 = BIT(16 + b) | (is_3v3 ? 0 : BIT(b));
>> > +	val1 = BIT(16 + b) | (is_3v3 ? BIT(b) : 0);
>> > +
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL0, val0);
>> > +	regmap_write(iod->grf, RK3568_PMU_GRF_IO_VSEL1, val1);
>> > +	break;
>> > +	default:
>> > +	return -EINVAL;
>> > +	};
>> > +
>> > +	return 0;
>> > +}
>> > +
>> >   static int rockchip_iodomain_write(struct rockchip_iodomain_supply *supply,
>> >      int uV)
>> >   {
>> > @@ -136,7 +183,7 @@ static int rockchip_iodomain_notify(struct notifier_block *nb,
>> >   return NOTIFY_BAD;
>> >   }
>> >  
>> > -	ret = rockchip_iodomain_write(supply, uV);
>> > +	ret = supply->iod->write(supply, uV);
>> >   if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
>> >   return NOTIFY_BAD;
>> >  
>> > @@ -398,6 +445,22 @@ static const struct rockchip_iodomain_soc_data soc_data_rk3399_pmu = {
>> >   .init = rk3399_pmu_iodomain_init,
>> >   };
>> >  
>> > +static const struct rockchip_iodomain_soc_data soc_data_rk3568_pmu = {
>> > +	.grf_offset = 0x140,
>> > +	.supply_names = {
>> > +	"pmuio1",
>> > +	"pmuio2",
>> > +	"vccio1",
>> > +	"vccio2",
>> > +	"vccio3",
>> > +	"vccio4",
>> > +	"vccio5",
>> > +	"vccio6",
>> > +	"vccio7",
>> > +	},
>> > +	.write = rk3568_iodomain_write,
>> > +};
>> > +
>> >   static const struct rockchip_iodomain_soc_data soc_data_rv1108 = {
>> >   .grf_offset = 0x404,
>> >   .supply_names = {
>> > @@ -469,6 +532,10 @@ static const struct of_device_id rockchip_iodomain_match[] = {
>> >   .compatible = "rockchip,rk3399-pmu-io-voltage-domain",
>> >   .data = &soc_data_rk3399_pmu
>> >   },
>> > +	{
>> > +	.compatible = "rockchip,rk3568-pmu-io-voltage-domain",
>> > +	.data = &soc_data_rk3568_pmu
>> > +	},
>> >   {
>> >   .compatible = "rockchip,rv1108-io-voltage-domain",
>> >   .data = &soc_data_rv1108
>> > @@ -502,6 +569,11 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >   match = of_match_node(rockchip_iodomain_match, np);
>> >   iod->soc_data = match->data;
>> >  
>> > +	if (iod->soc_data->write)
>> > +	iod->write = iod->soc_data->write;
>> > +	else
>> > +	iod->write = rockchip_iodomain_write;
>> > +
>> >   parent = pdev->dev.parent;
>> >   if (parent && parent->of_node) {
>> >   iod->grf = syscon_node_to_regmap(parent->of_node);
>> > @@ -562,7 +634,7 @@ static int rockchip_iodomain_probe(struct platform_device *pdev)
>> >   supply->reg = reg;
>> >   supply->nb.notifier_call = rockchip_iodomain_notify;
>> >  
>> > -	ret = rockchip_iodomain_write(supply, uV);
>> > +	ret = iod->write(supply, uV);
>> >   if (ret) {
>> >   supply->reg = NULL;
>> >   goto unreg_notify;
>> >
>>
>
>
>
>
>
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2021-08-06  9:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-05 12:01 [PATCH v3 0/7] arm64: dts: rockchip: rk3568-evb1-v10: add sd card support Michael Riesch
2021-08-05 12:01 ` [PATCH v3 1/7] dt-bindings: power: add rk3568-pmu-io-domain support Michael Riesch
2021-08-13 18:54   ` Rob Herring
2021-08-05 12:01 ` [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support Michael Riesch
2021-08-05 13:05   ` Peter Geis
2021-08-05 16:27   ` Robin Murphy
2021-08-06  9:18     ` Heiko Stübner
2021-08-06  9:46       ` jay.xu [this message]
2021-08-06 10:27         ` Robin Murphy
2021-08-06 10:57           ` Peter Geis
2021-08-16  6:26             ` jay.xu
2021-08-05 12:01 ` [PATCH v3 3/7] arm64: dts: rockchip: enable io domains for rk356x Michael Riesch
2021-08-05 12:01 ` [PATCH v3 4/7] arm64: dts: rockchip: rk3568-evb1-v10: enable io domains Michael Riesch
2021-08-05 12:01 ` [PATCH v3 5/7] arm64: dts: rockchip: rk3568-evb1-v10: add regulators of rk809 pmic Michael Riesch
2021-08-05 12:01 ` [PATCH v3 6/7] arm64: dts: rockchip: rk3568-evb1-v10: add node for sd card Michael Riesch
2021-08-05 12:01 ` [PATCH v3 7/7] arm64: dts: rockchip: rk3568-evb1-v10: add pinctrl and alias to emmc node Michael Riesch
2021-08-14  7:33 ` [PATCH v3 0/7] arm64: dts: rockchip: rk3568-evb1-v10: add sd card support Heiko Stuebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2021080617460178513151@rock-chips.com \
    --to=jay.xu@rock-chips.com \
    --cc=cl@rock-chips.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=kever.yang@rock-chips.com \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=michael.riesch@wolfvision.net \
    --cc=pgwipeout@gmail.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=robh+dt@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=s.hauer@pengutronix.de \
    --cc=t.schramm@manjaro.org \
    --cc=ulf.hansson@linaro.org \
    --cc=xxm@rock-chips.com \
    --cc=zhangchangzhong@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox