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
next prev parent 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).