linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicolas Boichat <drinkcat@chromium.org>
To: Roger Lu <roger.lu@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>,
	Enric Balletbo Serra <eballetbo@gmail.com>,
	Kevin Hilman <khilman@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Nicolas Boichat <drinkcat@google.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Mark Rutland <mark.rutland@arm.com>, Nishanth Menon <nm@ti.com>,
	Angus Lin <Angus.Lin@mediatek.com>,
	Devicetree List <devicetree@vger.kernel.org>,
	"open list:THERMAL" <linux-pm@vger.kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Xiaoqing Liu <Xiaoqing.Liu@mediatek.com>,
	YT Lee <yt.lee@mediatek.com>, Fan Chen <fan.chen@mediatek.com>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	HenryC Chen <HenryC.Chen@mediatek.com>,
	Charles Yang <Charles.Yang@mediatek.com>,
	linux-arm Mailing List <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v10 3/7] [v10, 3/7]: soc: mediatek: SVS: introduce MTK SVS engine
Date: Mon, 4 Jan 2021 17:27:49 +0800	[thread overview]
Message-ID: <CANMq1KDxVLo=JAAq-gjybke1WiX03COwNX7sHsZDMF9USzSECw@mail.gmail.com> (raw)
In-Reply-To: <1609750266.20758.40.camel@mtksdaap41>

On Mon, Jan 4, 2021 at 4:51 PM Roger Lu <roger.lu@mediatek.com> wrote:
>
>
> Hi Nicolas,
>
> Thanks for all the advices.
>
> On Thu, 2020-12-31 at 10:10 +0800, Nicolas Boichat wrote:
> > On Sun, Dec 27, 2020 at 6:55 PM Roger Lu <roger.lu@mediatek.com> wrote:
[snip]
> > > +static int svs_adjust_pm_opp_volts(struct svs_bank *svsb, bool force_update)
> > > +{
> > > +       int tzone_temp, ret = -EPERM;
> >
> > No need to initialize ret.
>
> Oh, excuse me, some coding check tool warn that this `ret` might return
> without being uninitialized. Therefore, I'll keep the initialization.

Oh, you're right, there is a possible path where ret is not set. sgtm then.

>
> >
> > > +       u32 i, svsb_volt, opp_volt, temp_offset = 0;
> > > +
> > > +       mutex_lock(&svsb->lock);
> > > +
> > > +       /*
> > > +        * If svs bank is suspended, it means signed-off voltages are applied.
> > > +        * Don't need to update opp voltage anymore.
> > > +        */
> > > +       if (svsb->suspended && !force_update) {
> > > +               dev_notice(svsb->dev, "bank is suspended\n");
> > > +               ret = -EPERM;
> > > +               goto unlock_mutex;
> > > +       }
> > > +
> > > +       /* Get thermal effect */
> > > +       if (svsb->phase == SVSB_PHASE_MON) {
> > > +               if (svsb->temp > svsb->temp_upper_bound &&
> > > +                   svsb->temp < svsb->temp_lower_bound) {
> > > +                       dev_warn(svsb->dev, "svsb temp = 0x%x?\n", svsb->temp);
> > > +                       ret = -EINVAL;
> > > +                       goto unlock_mutex;
> > > +               }
> > > +
> > > +               ret = svs_get_bank_zone_temperature(svsb->tzone_name,
> > > +                                                   &tzone_temp);
> > > +               if (ret) {
> > > +                       dev_err(svsb->dev, "no \"%s\"?(%d)?\n",
> > > +                               svsb->tzone_name, ret);
> > > +                       dev_err(svsb->dev, "set signed-off voltage\n");
> >
> > Please merge the error message in one line (I'm not sure what "set
> > signed-off voltage" means here).
>
> 1. Ok, I'll merge them. Thanks.
> 2. signed-off voltages means CPU DVFS default voltages

So just write "default voltages" then? ,-)

>
> >
[snip]
> > > +static irqreturn_t svs_isr(int irq, void *data)
> > > +{
> > > +       struct svs_platform *svsp = (struct svs_platform *)data;
> >
> > cast not needed.
>
> Ok, I'll remove it. Thanks.
>
> >
> > > +       struct svs_bank *svsb = NULL;
> > > +       unsigned long flags;
> > > +       u32 idx, int_sts, svs_en;
> > > +
> > > +       for (idx = 0; idx < svsp->bank_num; idx++) {
> > > +               svsb = &svsp->banks[idx];
> > > +
> > > +               spin_lock_irqsave(&mtk_svs_lock, flags);
> > > +               svsp->pbank = svsb;
> > > +
> > > +               /* Find out which svs bank fires interrupt */
> > > +               if (svsb->int_st & svs_readl(svsp, INTST)) {
> > > +                       spin_unlock_irqrestore(&mtk_svs_lock, flags);
> > > +                       continue;
> > > +               }
> > > +
> > > +               if (!svsb->suspended) {
> > > +                       svs_switch_bank(svsp);
> > > +                       int_sts = svs_readl(svsp, INTSTS);
> > > +                       svs_en = svs_readl(svsp, SVSEN);
> > > +
> > > +                       if (int_sts == SVSB_INTSTS_COMPLETE &&
> > > +                           ((svs_en & SVSB_EN_MASK) == SVSB_EN_INIT01))
> > > +                               svs_init01_isr_handler(svsp);
> > > +                       else if ((int_sts == SVSB_INTSTS_COMPLETE) &&
> > > +                                ((svs_en & SVSB_EN_MASK) == SVSB_EN_INIT02))
> > > +                               svs_init02_isr_handler(svsp);
> > > +                       else if (!!(int_sts & SVSB_INTSTS_MONVOP))
> >
> > !! is not required.
>
> Ok, I'll remove it. Thanks.
>
> >
> > > +                               svs_mon_mode_isr_handler(svsp);
> > > +                       else
> > > +                               svs_error_isr_handler(svsp);
> > > +               }
> > > +
> > > +               spin_unlock_irqrestore(&mtk_svs_lock, flags);
> > > +               break;
> > > +       }
> >
> > This will panic if svsb is NULL, is that ok or do you want to catch that?
>
> Oh, it is fine. Thanks for the heads-up.

I should have been stronger in my statement, I think you want to add a
BUG_ON(!svsb) to crash in a slightly more predictable manner.

[snip]
> > > +
> > > +       svsp->tefuse = (u32 *)nvmem_cell_read(cell, &svsp->tefuse_num);
> >
> > Cast not needed.
>
> Ok, I'll remove it if build/test ok. Because nvmem_cell_read returns
> (void *).
>
> >
> > Also, this need to be freed somewhere in remove code (kfree(svsp->tefuse)).
> >
> > And it seems like svsp->tefuse is only used in this function, can you
> > just allocate it here?
>
> Oh, svsp->tefuse will be used in SVS debug patch for debug purpose. So,
> I need to save it as struct member.

Oh I missed that, sgtm then. Thanks.

>
[snip]

  reply	other threads:[~2021-01-04  9:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-27 10:54 [PATCH v10 0/7] soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2020-12-27 10:54 ` [PATCH v10 1/7] [v10,1/7]: dt-bindings: soc: mediatek: add mtk svs dt-bindings Roger Lu
2020-12-27 16:56   ` [PATCH v10 1/7] [v10, 1/7]: " Rob Herring
2020-12-31 18:12   ` [PATCH v10 1/7] [v10,1/7]: " Rob Herring
2020-12-27 10:54 ` [PATCH v10 2/7] [v10,2/7]: arm64: dts: mt8183: add svs device information Roger Lu
2020-12-27 10:54 ` [PATCH v10 3/7] [v10,3/7]: soc: mediatek: SVS: introduce MTK SVS engine Roger Lu
2020-12-31  2:10   ` [PATCH v10 3/7] [v10, 3/7]: " Nicolas Boichat
2021-01-04  8:51     ` Roger Lu
2021-01-04  9:27       ` Nicolas Boichat [this message]
2021-01-04  9:52         ` Roger Lu
2021-01-06  8:41       ` Roger Lu
2021-01-06  8:44         ` Nicolas Boichat
2020-12-27 10:54 ` [PATCH v10 4/7] [v10,4/7]: soc: mediatek: SVS: add debug commands Roger Lu
2020-12-27 10:54 ` [PATCH v10 5/7] [v10,5/7]: dt-bindings: soc: mediatek: add mt8192 svs dt-bindings Roger Lu
2020-12-27 10:54 ` [PATCH v10 6/7] [v10,6/7]: arm64: dts: mt8192: add svs device information Roger Lu
2020-12-27 10:54 ` [PATCH v10 7/7] [v10,7/7]: soc: mediatek: SVS: add mt8192 SVS GPU driver Roger Lu

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='CANMq1KDxVLo=JAAq-gjybke1WiX03COwNX7sHsZDMF9USzSECw@mail.gmail.com' \
    --to=drinkcat@chromium.org \
    --cc=Angus.Lin@mediatek.com \
    --cc=Charles.Yang@mediatek.com \
    --cc=HenryC.Chen@mediatek.com \
    --cc=Xiaoqing.Liu@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@google.com \
    --cc=eballetbo@gmail.com \
    --cc=fan.chen@mediatek.com \
    --cc=khilman@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matthias.bgg@gmail.com \
    --cc=nm@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh+dt@kernel.org \
    --cc=roger.lu@mediatek.com \
    --cc=sboyd@kernel.org \
    --cc=yt.lee@mediatek.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;
as well as URLs for NNTP newsgroup(s).