Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support

From: Peter Geis
Date: Fri Aug 06 2021 - 06:58:06 EST

Next message: Mark Brown: "Re: [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed"
Previous message: Joao Martins: "Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region"
In reply to: Robin Murphy: "Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support"
Next in thread: Michael Riesch: "[PATCH v3 3/7] arm64: dts: rockchip: enable io domains for rk356x"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, Aug 6, 2021 at 6:28 AM Robin Murphy <robin.murphy@xxxxxxx> wrote:
>
> On 2021-08-06 10:46, jay.xu@xxxxxxxxxxxxxx wrote:
> > Hi Heiko and Robin
> >
> > --------------
> > jay.xu@xxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxx>
> >>>>
> >>>> 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
>
> Thanks Jay, that's useful to know.
>
> Fair enough if it's the case that 2.5V mode hasn't been validated with
> the BSP kernel either - I'd have no objection to clarifying the commit
> message that way instead, I'm just a curious reviewer who noticed some
> ambiguity :)
>
> >> Adding this later when needed should be somewhat easy, as it really only
> >> needs adding of handling that 3rd control bit per domain.
>
> I'm mostly just thinking ahead a year or two when board designers have
> ventured further away from the reference design and *are* using 2.5V
> external components, then a user puts an older stable mainline kernel on
> their board and starts tearing their hair out trying to figure out why
> things are flaky. For instance I recall from my RK3328 box that if the
> I/O domain setting for the GMAC is too high for the actual supply
> voltage (such that it never detects MDIO responses from the external
> phy) you end up getting an utterly nonsensical DMA error. In that case I
> eventually figured out (by chance) that it was because I didn't have the
> I/O domain driver enabled in my config, but it would be a whole other
> level of frustration if the driver appeared to be working but was
> quietly doing the wrong thing.

I too have experienced the joys of io-domains breaking things.
Perhaps the driver should warn when the voltages aren't expected,
instead of when they are simply too high.

>
> Cheers,
> Robin.
>
> >>
> >>
> >> 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@xxxxxxxxxxxxxx>
> >>>> ---
> >>>> 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;
> >>>>
> >>>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >

Next message: Mark Brown: "Re: [BUG] mmc_regulator_set_ocr can't cope with regulator-fixed"
Previous message: Joao Martins: "Re: [PATCH] selftests: KVM: avoid failures due to reserved HyperTransport region"
In reply to: Robin Murphy: "Re: [PATCH v3 2/7] soc: rockchip: io-domain: add rk3568 support"
Next in thread: Michael Riesch: "[PATCH v3 3/7] arm64: dts: rockchip: enable io domains for rk356x"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]