All of lore.kernel.org
 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;
>   };
>   
>   /**

WARNING: multiple messages have this Message-ID (diff)
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:49 UTC|newest]

Thread overview: 36+ 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 ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 1/8] dt-bindings: power: Add MT8365 power domains Markus Schneider-Pargmann
2023-01-05 17:07   ` Markus Schneider-Pargmann
2023-01-08 22:07   ` Rob Herring
2023-01-08 22:07     ` Rob Herring
2023-02-03 12:31   ` Matthias Brugger
2023-02-03 12:31     ` Matthias Brugger
2023-02-20 20:10     ` Markus Schneider-Pargmann
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   ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 3/8] soc: mediatek: pm-domains: Create bus protection operation functions Markus Schneider-Pargmann
2023-01-05 17:07   ` Markus Schneider-Pargmann
2023-02-03 12:32   ` Matthias Brugger
2023-02-03 12:32     ` Matthias Brugger
2023-03-13 11:49     ` Markus Schneider-Pargmann
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   ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 5/8] soc: mediatek: pm-domains: Fix caps field documentation Markus Schneider-Pargmann
2023-01-05 17:07   ` Markus Schneider-Pargmann
2023-02-03 11:14   ` Matthias Brugger
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-01-05 17:07   ` Markus Schneider-Pargmann
2023-02-03 12:49   ` Matthias Brugger [this message]
2023-02-03 12:49     ` Matthias Brugger
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   ` Markus Schneider-Pargmann
2023-01-05 17:07 ` [PATCH 8/8] soc: mediatek: pm-domains: Add support for MT8365 Markus Schneider-Pargmann
2023-01-05 17:07   ` Markus Schneider-Pargmann
2023-02-03 12:22   ` Matthias Brugger
2023-02-03 12:22     ` Matthias Brugger
2023-02-20 19:44     ` Markus Schneider-Pargmann
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.