public inbox for linux-mediatek@lists.infradead.org
 help / color / mirror / Atom feed
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



      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