From: "Yu-chang Lee (李禹璋)" <Yu-chang.Lee@mediatek.com>
To: "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
"angelogioacchino.delregno@collabora.com"
<angelogioacchino.delregno@collabora.com>,
"msp@baylibre.com" <msp@baylibre.com>
Cc: "fparent@baylibre.com" <fparent@baylibre.com>,
"linux-mediatek@lists.infradead.org"
<linux-mediatek@lists.infradead.org>,
"Ben Lok (陸志恆)" <ben.lok@mediatek.com>,
"Chris-qj Chen (陳奇進)" <Chris-qj.Chen@mediatek.com>,
"Louis Yu (游政錕)" <louis.yu@mediatek.com>,
"Bear Wang (萩原惟德)" <bear.wang@mediatek.com>,
"MandyJH Liu (劉人僖)" <MandyJH.Liu@mediatek.com>,
"amergnat@baylibre.com" <amergnat@baylibre.com>,
"afgros@baylibre.com" <afgros@baylibre.com>,
"Xiufeng Li (李秀峰)" <Xiufeng.Li@mediatek.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"Fan Chen (陳凡)" <fan.chen@mediatek.com>,
"abailon@baylibre.com" <abailon@baylibre.com>
Subject: Re: Discuss Mediatek Power Domain Driver Support Mulitle Smi Clamp Protection
Date: Mon, 25 Dec 2023 02:55:34 +0000 [thread overview]
Message-ID: <6fe4d15afc6220c0f131d33925b82dd24bedcd06.camel@mediatek.com> (raw)
In-Reply-To: <e80dbd42-b9c8-4564-be4e-6ee449d24c70@collabora.com>
On Thu, 2023-12-21 at 13:31 +0100, AngeloGioacchino Del Regno wrote:
> >
> > We can clamp IMG1 before clamping IMG0, I am more concerned with
> > the
> > order between infra and smi rather than the order between smi. And
> > I
> > think current structure mixed smi and infra may also introduce
> > misunderstanding in the future. Maybe separate the bp_cfg and match
> > the
> > smi name with smi's bus protection step could be a direction to fix
> > the
> > problem?
> >
>
> That could work, yes. You could alternatively build an array, or a 32
> bit value for
> which each bit corresponds to the position of a BUS_PROT_WR entry in
> .bp_cfg, and
> then use that to locate SMI vs INFRA bus protection entries.
>
> Taking as an example a "messy" bp_cfg:
>
> .bp_cfg = {
> BUS_PROT_WR(INFRA, other_params),
> BUS_PROT_WR(SMI, other_params),
> BUS_PROT_WR(INFRA, ...),
> BUS_PROT_WR(INFRA, ...),
> BUS_PROT_WR(SMI, ...),
> }
>
> probe_function() {
> ...
>
> for (....) {
> if (.bp_cfg[i] == SMI)
> pd->smi_bp_map |= BIT(i);
> }
>
> ....
> }
>
> powerup_function() {
> ...
> u16 smi_bp_map = pd->smi_bp_map;
>
> for_each_set_bit(i, &smi_pd_map, 16)
> bus_protect_smi_write(somewhere->bp_cfg[i]);
>
> ...
>
> bus_protect_infra_write()
>
> ...
> }
>
>
> Or, simply, we can *enforce* ordering in bp_cfg, so that all of the
> SMI entries
> are before INFRA, like:
>
> .bp_cfg = {
> /* Ordering is important here: SMI bus prot always before INFRA
> */
> BUS_PROT_WR(SMI, other_params),
> BUS_PROT_WR(SMI, ...),
> BUS_PROT_WR(INFRA, other_params),
> BUS_PROT_WR(INFRA, ...),
> BUS_PROT_WR(INFRA, ...),
> }
>
> ...so that we never build any positional information / bitmaps.
>
> Since the SMI vs INFRA order is really important, we could add a
> "failsafe" check
> in the probe function, like:
>
> probe() {
> bool smi_prot_found;
>
> for (....) {
> if ((...->bp_cfg[i].flags & BUS_PROT_COMPONENT_INFRA)
> &&
> smi_prot_found) {
> dev_err(... , "SMI bus prot cannot be mixed
> with INFRA");
> return -EINVAL;
> } else if (....->bp_cfg[i] & BUS_PROT_COMPONENT_SMI)
> smi_prot_found = true;
> }
> }
>
> Obviously the error message etc should be reworded, all the above is
> just
> examples to solve the issue without having any meaningful overhead in
> the
> performance paths [scpsys_power_on() and scpsys_power_off()].
>
> Does that help you?
>
> Cheers,
> Angelo
Hi Angelo:
Thanks for your generous feedback and advice, I will think about it.
See you upstream then.
Best Regards,
Yu-Chang.Lee
prev parent reply other threads:[~2023-12-25 3:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <a3aaf3180fdb3da117132089bd160ba4d5cebc17.camel@mediatek.com>
[not found] ` <b4fa9b7f-512f-4a34-884a-a99a3b035d34@collabora.com>
2023-12-21 8:29 ` Discuss Mediatek Power Domain Driver Support Mulitle Smi Clamp Protection Yu-chang Lee (李禹璋)
2023-12-21 12:31 ` AngeloGioacchino Del Regno
2023-12-25 2:55 ` Yu-chang Lee (李禹璋) [this message]
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=6fe4d15afc6220c0f131d33925b82dd24bedcd06.camel@mediatek.com \
--to=yu-chang.lee@mediatek.com \
--cc=Chris-qj.Chen@mediatek.com \
--cc=MandyJH.Liu@mediatek.com \
--cc=Xiufeng.Li@mediatek.com \
--cc=abailon@baylibre.com \
--cc=afgros@baylibre.com \
--cc=amergnat@baylibre.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bear.wang@mediatek.com \
--cc=ben.lok@mediatek.com \
--cc=fan.chen@mediatek.com \
--cc=fparent@baylibre.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=louis.yu@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=msp@baylibre.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