linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg@gmail.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Chun-Jie Chen <chun-jie.chen@mediatek.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.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 6/8] soc: mediatek: Add support for WAY_EN operations
Date: Fri, 3 Feb 2023 13:49:38 +0100	[thread overview]
Message-ID: <13bceff4-1b40-46bd-6b80-11564a147b8f@gmail.com> (raw)
In-Reply-To: <20230105170735.1637416-7-msp@baylibre.com>



On 05/01/2023 18:07, Markus Schneider-Pargmann wrote:
> 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 v4:
>      - Redesigned the patch to be better to understand and have less code
>        duplication
>      
>      Changes in v3:
>      - Separated the way_en functions for clarity
>      - Added some checks for infracfg_nao
>      
>      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 | 57 ++++++++++++++++++++-------
>   drivers/soc/mediatek/mtk-pm-domains.h | 16 ++++++--
>   2 files changed, 54 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.c b/drivers/soc/mediatek/mtk-pm-domains.c
> index 999e1f6c86b0..d53309f050ee 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.c
> +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> @@ -43,6 +43,7 @@ struct scpsys_domain {
>   	struct clk_bulk_data *clks;
>   	int num_subsys_clks;
>   	struct clk_bulk_data *subsys_clks;
> +	struct regmap *infracfg_nao;
>   	struct regmap *infracfg;
>   	struct regmap *smi;
>   	struct regulator *supply;
> @@ -118,10 +119,13 @@ static int scpsys_sram_disable(struct scpsys_domain *pd)
>   }
>   
>   static int scpsys_bus_protect_clear(const struct scpsys_bus_prot_data *bpd,
> -				    struct regmap *regmap)
> +				    struct regmap *regmap,
> +				    struct regmap *sta_regmap)

I had a look at this and I don't like the idea to add another regmap that's used 
based on flag in scpsys_bus_prot_data.

Up to now the assumption was that the different actions to enable/disable bus 
protection were done using one regmap. For this reason the regmap was defined 
once in scpsys_domain. It's not a good design to just pass more and more regmaps 
or other members to the functions. We should try to find a better way to 
structure the data so that it fulfills our needs.

Possible solutions I can think of right now:
a) Pass a struct of two regmaps to _scpsys_bus_protect_[disable,enable]()
We can pass the second regmap only if pd->way_en is set, otherwise it will be 
ignored anyway.
It's less flexible if in the future we need another regmap. We will have two a 
flag to mark we use way_en twice, in struct scpsys_domain and in struct 
scpsys_domain_data. Please see my comment below. It's something else to think about.


b) Add a flag field to scpsys_bus_prot_data to say explicitely if we want to use 
infracfg, smi with/without way_en. Then we can pass all three regmaps in a 
struct, it will be easy to add new regmaps in the future.
Downsides:
1) We will overload even more the _BUS_PROT macros, which get's hard to read and 
understand already. Maybe that can somehow be fixed. An idea would be by adding 
a bit field to scpsys_bus_prot_data.
2) We will need to rework all the scpsys_domain_data structures for all SoCs 
already supported. It's doable, but it's some extra work.

Any other ideas?

>   {
>   	u32 val;
>   	u32 sta_mask = bpd->bus_prot_sta_mask;
> +	/* way_en acknowledges successful clear with the bit being set */
> +	u32 expected_ack = (bpd->way_en ? sta_mask : 0);
>   
>   	if (bpd->bus_prot_reg_update)
>   		regmap_clear_bits(regmap, bpd->bus_prot_clr, bpd->bus_prot_set_clr_mask);
> @@ -131,13 +135,14 @@ static int scpsys_bus_protect_clear(const struct scpsys_bus_prot_data *bpd,
>   	if (bpd->ignore_clr_ack)
>   		return 0;
>   
> -	return regmap_read_poll_timeout(regmap, bpd->bus_prot_sta,
> -					val, !(val & sta_mask),
> +	return regmap_read_poll_timeout(sta_regmap, bpd->bus_prot_sta,
> +					val, (val & sta_mask) == expected_ack,
>   					MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
>   }
>   
>   static int scpsys_bus_protect_set(const struct scpsys_bus_prot_data *bpd,
> -				  struct regmap *regmap)
> +				  struct regmap *regmap,
> +				  struct regmap *sta_regmap)
>   {
>   	u32 val;
>   	u32 sta_mask = bpd->bus_prot_sta_mask;
> @@ -147,12 +152,13 @@ static int scpsys_bus_protect_set(const struct scpsys_bus_prot_data *bpd,
>   	else
>   		regmap_write(regmap, bpd->bus_prot_set, bpd->bus_prot_set_clr_mask);
>   
> -	return regmap_read_poll_timeout(regmap, bpd->bus_prot_sta,
> +	return regmap_read_poll_timeout(sta_regmap, bpd->bus_prot_sta,
>   					val, (val & sta_mask) == sta_mask,
>   					MTK_POLL_DELAY_US, 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;
>   
> @@ -160,9 +166,14 @@ static int _scpsys_bus_protect_enable(const struct scpsys_bus_prot_data *bpd, st
>   		if (!bpd[i].bus_prot_set_clr_mask)
>   			break;
>   
> -		ret = scpsys_bus_protect_set(&bpd[i], regmap);
> -		if (ret)
> +		if (bpd[i].way_en)
> +			ret = scpsys_bus_protect_clear(&bpd[i], regmap, infracfg_nao);
> +		else
> +			ret = scpsys_bus_protect_set(&bpd[i], regmap, regmap);
> +		if (ret) {
> +			pr_err("%s %d %d\n", __PRETTY_FUNCTION__, __LINE__, ret);
>   			return ret;
> +		}
>   	}
>   
>   	return 0;
> @@ -172,15 +183,17 @@ 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);
>   }
>   
>   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;
>   
> @@ -188,9 +201,14 @@ static int _scpsys_bus_protect_disable(const struct scpsys_bus_prot_data *bpd,
>   		if (!bpd[i].bus_prot_set_clr_mask)
>   			continue;
>   
> -		ret = scpsys_bus_protect_clear(&bpd[i], regmap);
> -		if (ret)
> +		if (bpd[i].way_en)
> +			ret = scpsys_bus_protect_set(&bpd[i], regmap, infracfg_nao);
> +		else
> +			ret = scpsys_bus_protect_clear(&bpd[i], regmap, regmap);
> +		if (ret) {
> +			pr_err("%s %d %d\n", __PRETTY_FUNCTION__, __LINE__, ret);
>   			return ret;
> +		}
>   	}
>   
>   	return 0;
> @@ -200,11 +218,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)
> @@ -378,6 +397,14 @@ 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(node, "mediatek,infracfg-nao");
> +	if (IS_ERR(pd->infracfg_nao)) {
> +		if (MTK_SCPD_CAPS(pd, MTK_SCPD_HAS_WAY_EN))
> +			return ERR_CAST(pd->infracfg_nao);

I don't like the fact that we have a caps to show we have WAY_EN and then we 
have a bool in scpsys_bus_prot_data to flag when we need to use the second 
regmap and the expected_ack mask.
Can't we just make the lookup optional and let it all blow up if DTS is wrong 
because no infracfg-nao was defined while there is at least one domain using way_en?

Regards,
Matthias

> +
> +		pd->infracfg_nao = NULL;
> +	}
> +
>   	num_clks = of_clk_get_parent_count(node);
>   	if (num_clks > 0) {
>   		/* Calculate number of subsys_clks */
> diff --git a/drivers/soc/mediatek/mtk-pm-domains.h b/drivers/soc/mediatek/mtk-pm-domains.h
> index 34642a279213..1fa634509db1 100644
> --- a/drivers/soc/mediatek/mtk-pm-domains.h
> +++ b/drivers/soc/mediatek/mtk-pm-domains.h
> @@ -10,6 +10,7 @@
>   #define MTK_SCPD_DOMAIN_SUPPLY		BIT(4)
>   /* can't set MTK_SCPD_KEEP_DEFAULT_OFF at the same time */
>   #define MTK_SCPD_ALWAYS_ON		BIT(5)
> +#define MTK_SCPD_HAS_WAY_EN		BIT(6)
>   #define MTK_SCPD_CAPS(_scpd, _x)	((_scpd)->data->caps & (_x))
>   
>   #define SPM_VDE_PWR_CON			0x0210
> @@ -41,7 +42,7 @@
>   
>   #define SPM_MAX_BUS_PROT_DATA		6
>   
> -#define _BUS_PROT(_set_clr_mask, _set, _clr, _sta_mask, _sta, _update, _ignore) {	\
> +#define _BUS_PROT(_set_clr_mask, _set, _clr, _sta_mask, _sta, _update, _ignore, _way_en) {	\
>   		.bus_prot_set_clr_mask = (_set_clr_mask),	\
>   		.bus_prot_set = _set,				\
>   		.bus_prot_clr = _clr,				\
> @@ -49,16 +50,20 @@
>   		.bus_prot_sta = _sta,				\
>   		.bus_prot_reg_update = _update,			\
>   		.ignore_clr_ack = _ignore,			\
> +		.way_en = _way_en,				\
>   	}
>   
>   #define BUS_PROT_WR(_mask, _set, _clr, _sta)			\
> -		_BUS_PROT(_mask, _set, _clr, _mask, _sta, false, false)
> +		_BUS_PROT(_mask, _set, _clr, _mask, _sta, false, false, false)
>   
>   #define BUS_PROT_WR_IGN(_mask, _set, _clr, _sta)		\
> -		_BUS_PROT(_mask, _set, _clr, _mask, _sta, false, true)
> +		_BUS_PROT(_mask, _set, _clr, _mask, _sta, false, true, false)
>   
>   #define BUS_PROT_UPDATE(_mask, _set, _clr, _sta)		\
> -		_BUS_PROT(_mask, _set, _clr, _mask, _sta, true, false)
> +		_BUS_PROT(_mask, _set, _clr, _mask, _sta, true, false, false)
> +
> +#define BUS_PROT_WAY_EN(_set_mask, _set, _sta_mask, _sta)	\
> +		_BUS_PROT(_set_mask, _set, _set, _sta_mask, _sta, true, false, true)
>   
>   #define BUS_PROT_UPDATE_TOPAXI(_mask)				\
>   		BUS_PROT_UPDATE(_mask,				\
> @@ -77,6 +82,8 @@
>    *			 write the whole register.
>    * @ignore_clk_ack: Ignore the result in the status register for clear
>    *		    operations.
> + * @way_en: Enable a way in the SoC. For this type the status bit to acknowledge
> + *	    the change is always 1 on successful change.
>    */
>   struct scpsys_bus_prot_data {
>   	u32 bus_prot_set_clr_mask;
> @@ -86,6 +93,7 @@ struct scpsys_bus_prot_data {
>   	u32 bus_prot_sta;
>   	bool bus_prot_reg_update;
>   	bool ignore_clr_ack;
> +	bool way_en;
>   };
>   
>   /**

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-02-03 12:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05 17:07 [PATCH 0/8] soc: mediatek: MT8365 power support Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 1/8] dt-bindings: power: Add MT8365 power domains Markus Schneider-Pargmann
2023-01-08 22:07   ` Rob Herring
2023-02-03 12:31   ` Matthias Brugger
2023-02-20 20:10     ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 2/8] soc: mediatek: pm-domains: Split bus_prot_mask Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 3/8] soc: mediatek: pm-domains: Create bus protection operation functions Markus Schneider-Pargmann
2023-02-03 12:32   ` Matthias Brugger
2023-03-13 11:49     ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 4/8] soc: mediatek: pm-domains: Document scpsys_bus_prot_data Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 5/8] soc: mediatek: pm-domains: Fix caps field documentation Markus Schneider-Pargmann
2023-02-03 11:14   ` Matthias Brugger
2023-01-05 17:07 ` [PATCH 6/8] soc: mediatek: Add support for WAY_EN operations Markus Schneider-Pargmann
2023-02-03 12:49   ` Matthias Brugger [this message]
2023-01-05 17:07 ` [PATCH 7/8] soc: mediatek: Add support for MTK_SCPD_STRICT_BUS_PROTECTION cap Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 8/8] soc: mediatek: pm-domains: Add support for MT8365 Markus Schneider-Pargmann
2023-02-03 12:22   ` Matthias Brugger
2023-02-20 19:44     ` 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=13bceff4-1b40-46bd-6b80-11564a147b8f@gmail.com \
    --to=matthias.bgg@gmail.com \
    --cc=abailon@baylibre.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chun-jie.chen@mediatek.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=msp@baylibre.com \
    --cc=parent.f@gmail.com \
    --cc=robh+dt@kernel.org \
    /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).