devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Markus Schneider-Pargmann <msp@baylibre.com>
To: AngeloGioacchino Del Regno  <angelogioacchino.delregno@collabora.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Weiyi Lu <weiyi.lu@mediatek.com>,
	Fabien Parent <parent.f@gmail.com>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org,
	Alexandre Bailon <abailon@baylibre.com>,
	Fabien Parent <fparent@baylibre.com>
Subject: Re: [PATCH v2 2/4] soc: mediatek: Add support of WAY_EN operations
Date: Fri, 19 Aug 2022 14:42:06 +0200	[thread overview]
Message-ID: <20220819124206.kwp6ammicyy4z3jb@blmsp> (raw)
In-Reply-To: <dccc2863-a9db-d9ea-01e1-a18cf0db1d1e@collabora.com>

Hi Angelo,

Thanks for your review, I fixed most, comments inline.

On Mon, Jul 25, 2022 at 11:55:27AM +0200, AngeloGioacchino Del Regno wrote:
> Il 25/07/22 10:18, Markus Schneider-Pargmann ha scritto:
> > From: Alexandre Bailon <abailon@baylibre.com>
> > 
> > This updates the power domain to support WAY_EN operations. These
> > operations enable a path between different units of the chip and are
> > labeled as 'way_en' in the register descriptions.
> > 
> > This operation is required by the mt8365 for the MM power domain.
> > 
> > Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
> > Signed-off-by: Fabien Parent <fparent@baylibre.com>
> > Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
> > ---
> > 
> > Notes:
> >      Changes in v2:
> >      - some minor style fixes.
> >      - Renamed 'wayen' to 'way_en' to clarify the meaning
> >      - Updated commit message
> > 
> >   drivers/soc/mediatek/mtk-pm-domains.c | 64 +++++++++++++++++++++------
> >   drivers/soc/mediatek/mtk-pm-domains.h | 28 +++++++-----
> >   2 files changed, 68 insertions(+), 24 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
> > index 5ced254b082b..d0eae2227813 100644
> > --- a/drivers/soc/mediatek/mtk-pm-domains.c
> > +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> > @@ -44,6 +44,7 @@ struct scpsys_domain {
> >   	struct clk_bulk_data *subsys_clks;
> >   	struct regmap *infracfg;
> >   	struct regmap *smi;
> > +	struct regmap *infracfg_nao;
> 
> What does "nao" mean?

I couldn't find the meaning of nao right now. It is the name of the
infracfg node in the datasheet. The normal one is called 'infracfg_ao'
the other one 'infracfg_nao' as far as I can see.

> 
> Besides, please move that before *infracfg to at least keep the same type members
> alphabetically sorted..
> 
> >   	struct regulator *supply;
> >   };
> > @@ -116,23 +117,38 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
> >   					MTK_POLL_TIMEOUT);
> >   }
> > -static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd, struct regmap *regmap)
> > +static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd,
> > +				      struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = 0; i < SPM_MAX_BUS_PROT_DATA; i++) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 mask = bpd[i].bus_prot_mask;
> > +		u32 val = mask, sta_mask = mask;
> 
> You have modified the macros to use sta_mask as mask, so, why are you doing
> that distinction in here between the two? You can simply keep assigning
> 
> 		u32 mask = bpd[1].bus_prot_mask;
> 		u32 sta_mask = bpd[1].bus_prot_sta_mask;
> 
> > +		struct regmap *ack_regmap = regmap;
> 
> Double assignment. You're reassigning this if way_en == true.
> 
> >   		if (!mask)
> >   			break;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = 0;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> 
> 		if (bpd[i].way_en) {
> 			ack_regmap = regmap_nao;
> 			val = 0;
> 		} else {
> 			ack_regmap = regmap;
> 			val = mask;
> 		}
> 
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_set_bits(regmap, bpd[i].bus_prot_set, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_set, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_set, mask);
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, (val & mask) == mask,
> > +		if (bpd[i].ignore_clr_ack)
> > +			continue;
> 
> You're adding that ignore_clr_ack here in the bus prot enablement function
> which wasn't here before... and I didn't check carefully, but I think that
> this is wrong: as the name says, it's to "ignore CLEAR ack", we're not doing
> any clearing here, we're not in bus_protect_disable.
> 
> If you're really sure that this is not a mistake, you should guard it for way_en.

We are clearing bits here if way_en is true and bus_prot_reg_update is
true as well. Then val=0 and regmap_update_bits(..., mask, val) will
clear the bits given in mask. And yes either way_en or val==0 should
probably be checked here. Thanks.

> 
> > +
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, (val & sta_mask) == sta_mask,
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -145,34 +161,49 @@ static int scpsys_bus_protect_enable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg, pd->infracfg);
> > +	ret = _scpsys_bus_protect_enable(pd->data->bp_infracfg,
> > +					 pd->infracfg, pd->infracfg_nao);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi);
> > +	return _scpsys_bus_protect_enable(pd->data->bp_smi, pd->smi, NULL);
> >   }
> > +#define mask_cond(way_en, val, mask) \
> > +	((way_en && ((val & mask) == mask)) || (!way_en && !(val & mask)))
> > +
> >   static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
> > -				       struct regmap *regmap)
> > +				       struct regmap *regmap, struct regmap *infracfg_nao)
> >   {
> >   	int i, ret;
> >   	for (i = SPM_MAX_BUS_PROT_DATA - 1; i >= 0; i--) {
> > -		u32 val, mask = bpd[i].bus_prot_mask;
> > +		u32 val = 0, mask = bpd[i].bus_prot_mask;
> > +		u32 sta_mask = mask;
> > +		struct regmap *ack_regmap = regmap;
> >   		if (!mask)
> >   			continue;
> > +		if (bpd[i].way_en) {
> > +			if (!infracfg_nao)
> > +				return -ENODEV;
> > +
> > +			val = mask;
> > +			sta_mask = bpd[i].bus_prot_sta_mask;
> > +			ack_regmap = infracfg_nao;
> > +		}
> > +
> >   		if (bpd[i].bus_prot_reg_update)
> > -			regmap_clear_bits(regmap, bpd[i].bus_prot_clr, mask);
> > +			regmap_update_bits(regmap, bpd[i].bus_prot_clr, mask, val);
> >   		else
> >   			regmap_write(regmap, bpd[i].bus_prot_clr, mask);
> >   		if (bpd[i].ignore_clr_ack)
> >   			continue;
> > -		ret = regmap_read_poll_timeout(regmap, bpd[i].bus_prot_sta,
> > -					       val, !(val & mask),
> > +		ret = regmap_read_poll_timeout(ack_regmap, bpd[i].bus_prot_sta,
> > +					       val, mask_cond(bpd[i].way_en, val, sta_mask),
> 
> "I don't know why", my brain still keeps telling me that using different functions
> for the WAY_EN (en/dis) is just better.
> 
> This commit seems to be overcomplicating two "easy" en/dis functions.

Looking at the code again, I think you are right. I redesigned basically
this whole patch, and I think it is easier to understand now.
> 
> >   					       MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> >   		if (ret)
> >   			return ret;
> > @@ -185,11 +216,12 @@ static int scpsys_bus_protect_disable(struct scpsys_domain *pd)
> >   {
> >   	int ret;
> > -	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi);
> > +	ret = _scpsys_bus_protect_disable(pd->data->bp_smi, pd->smi, NULL);
> >   	if (ret)
> >   		return ret;
> > -	return _scpsys_bus_protect_disable(pd->data->bp_infracfg, pd->infracfg);
> > +	return _scpsys_bus_protect_disable(pd->data->bp_infracfg,
> > +			pd->infracfg, pd->infracfg_nao);
> >   }
> >   static int scpsys_regulator_enable(struct regulator *supply)
> > @@ -363,6 +395,10 @@ generic_pm_domain *scpsys_add_one_domain(struct scpsys *scpsys, struct device_no
> >   			return ERR_CAST(pd->smi);
> >   	}
> > +	pd->infracfg_nao = syscon_regmap_lookup_by_phandle_optional(node, "mediatek,infracfg_nao");
> > +	if (IS_ERR(pd->infracfg_nao))
> > +		return ERR_CAST(pd->infracfg_nao);
> > +
> 
> I think that we should enforce a check here:
> 
> pd->infracfg_nao = syscon_regmap_lookup_by_phandle(node, "mediatek,infracfg_nao");
> if (IS_ERR(pd->infracfg_nao)) {
> 	/* checking if infracfg_nao != NULL at every pwoeron/poweroff is largely
> 	 * suboptimal, as if it't present once, it's present always (!)
> 	 */
> 	if (we have WAY_EN)
> 		return ERR_CAST ...
> 	pd->infracfg_nao = NULL;
> }

Yes, I added another check that enforces .bp_smi not having any way_en
configuration.

Thanks,
Markus

  reply	other threads:[~2022-08-19 12:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25  8:18 [PATCH v2 0/4] soc: mediatek: MT8365 power support Markus Schneider-Pargmann
2022-07-25  8:18 ` [PATCH v2 1/4] dt-bindings: power: Add MT8365 power domains Markus Schneider-Pargmann
2022-07-25  8:54   ` AngeloGioacchino Del Regno
2022-08-11 10:14     ` Markus Schneider-Pargmann
2022-08-11 10:45       ` Krzysztof Kozlowski
2022-07-25  8:18 ` [PATCH v2 2/4] soc: mediatek: Add support of WAY_EN operations Markus Schneider-Pargmann
2022-07-25  9:55   ` AngeloGioacchino Del Regno
2022-08-19 12:42     ` Markus Schneider-Pargmann [this message]
2022-07-25  8:18 ` [PATCH v2 3/4] soc: mediatek: add support of MTK_SCPD_STRICT_BUSP cap Markus Schneider-Pargmann
2022-07-25  9:07   ` AngeloGioacchino Del Regno
2022-07-25  8:18 ` [PATCH v2 4/4] soc: mediatek: pm-domains: Add support for MT8365 Markus Schneider-Pargmann

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=20220819124206.kwp6ammicyy4z3jb@blmsp \
    --to=msp@baylibre.com \
    --cc=abailon@baylibre.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fparent@baylibre.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=parent.f@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=weiyi.lu@mediatek.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;
as well as URLs for NNTP newsgroup(s).