From: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Argus Lin <argus.lin@mediatek.com>, <drinkcat@chromium.org>,
<devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>, <hsin-hsiung.wang@mediatek.com>
Subject: Re: [PATCH v3 2/4] soc: mediatek: pwrap: add arbiter capability
Date: Wed, 18 Nov 2020 19:40:58 +0800 [thread overview]
Message-ID: <1605699658.24420.3.camel@mtksdaap41> (raw)
In-Reply-To: <46c0e204-b5e2-4ee3-678b-e09844442aad@gmail.com>
Hi,
On Mon, 2020-09-21 at 18:48 +0200, Matthias Brugger wrote:
>
> On 21/09/2020 13:03, Hsin-Hsiung Wang wrote:
> > Add arbiter capability for pwrap driver.
>
> Can you provide a bit more verbose commit message, please.
>
Thanks for reviewing. I will update it in next patch.
> > This patch is preparing for adding mt6873/8192 pwrap support.
> >
> > Signed-off-by: Hsin-Hsiung Wang <hsin-hsiung.wang@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-pmic-wrap.c | 57 ++++++++++++++++++++++++++++++------
> > 1 file changed, 48 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index c897205..149bf02 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -25,10 +25,12 @@
> >
> > /* macro for wrapper status */
> > #define PWRAP_GET_WACS_RDATA(x) (((x) >> 0) & 0x0000ffff)
> > +#define PWRAP_GET_WACS_ARB_FSM(x) (((x) >> 1) & 0x00000007)
> > #define PWRAP_GET_WACS_FSM(x) (((x) >> 16) & 0x00000007)
> > #define PWRAP_GET_WACS_REQ(x) (((x) >> 19) & 0x00000001)
> > #define PWRAP_STATE_SYNC_IDLE0 BIT(20)
> > #define PWRAP_STATE_INIT_DONE0 BIT(21)
> > +#define PWRAP_STATE_INIT_DONE1 BIT(15)
> >
> > /* macro for WACS FSM */
> > #define PWRAP_WACS_FSM_IDLE 0x00
> > @@ -74,6 +76,7 @@
> > #define PWRAP_CAP_DCM BIT(2)
> > #define PWRAP_CAP_INT1_EN BIT(3)
> > #define PWRAP_CAP_WDT_SRC1 BIT(4)
> > +#define PWRAP_CAP_ARB BIT(5)
> >
> > /* defines for slave device wrapper registers */
> > enum dew_regs {
> > @@ -340,6 +343,8 @@ enum pwrap_regs {
> > PWRAP_DCM_DBC_PRD,
> > PWRAP_EINT_STA0_ADR,
> > PWRAP_EINT_STA1_ADR,
> > + PWRAP_SWINF_2_WDATA_31_0,
> > + PWRAP_SWINF_2_RDATA_31_0,
> >
> > /* MT2701 only regs */
> > PWRAP_ADC_CMD_ADDR,
> > @@ -1108,14 +1113,22 @@ static void pwrap_writel(struct pmic_wrapper *wrp, u32 val, enum pwrap_regs reg)
> >
> > static bool pwrap_is_fsm_idle(struct pmic_wrapper *wrp)
> > {
> > - u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> > + u32 val;
> > +
> > + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + return PWRAP_GET_WACS_ARB_FSM(val) == PWRAP_WACS_FSM_IDLE;
> >
> > return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_IDLE;
> > }
> >
> > static bool pwrap_is_fsm_vldclr(struct pmic_wrapper *wrp)
> > {
> > - u32 val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> > + u32 val;
> > +
> > + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + return PWRAP_GET_WACS_ARB_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR;
> >
> > return PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR;
> > }
> > @@ -1165,6 +1178,7 @@ static int pwrap_wait_for_state(struct pmic_wrapper *wrp,
> > static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
> > {
> > int ret;
> > + u32 val;
> >
> > ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
> > if (ret) {
> > @@ -1172,13 +1186,21 @@ static int pwrap_read16(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
> > return ret;
> > }
> >
> > - pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);
> > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + val = adr;
> > + else
> > + val = (adr >> 1) << 16;
> > + pwrap_writel(wrp, val, PWRAP_WACS2_CMD);
> >
> > ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_vldclr);
> > if (ret)
> > return ret;
> >
> > - *rdata = PWRAP_GET_WACS_RDATA(pwrap_readl(wrp, PWRAP_WACS2_RDATA));
> > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + val = pwrap_readl(wrp, PWRAP_SWINF_2_RDATA_31_0);
> > + else
> > + val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
> > + *rdata = PWRAP_GET_WACS_RDATA(val);
> >
> > pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
> >
> > @@ -1228,8 +1250,13 @@ static int pwrap_write16(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
> > return ret;
> > }
> >
> > - pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
> > - PWRAP_WACS2_CMD);
> > + if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB)) {
>
> Please switch if's so that we take the else branch on the arbiter not present
> case. Or the other way round, just make it uniform, where possible, of course.
>
Thanks, I will update it in next patch.
> > + pwrap_writel(wrp, BIT(31) | ((adr >> 1) << 16) | wdata,
> > + PWRAP_WACS2_CMD);
> > + } else {
> > + pwrap_writel(wrp, wdata, PWRAP_SWINF_2_WDATA_31_0);
> > + pwrap_writel(wrp, BIT(29) | adr, PWRAP_WACS2_CMD);
> > + }
> >
> > return 0;
> > }
> > @@ -2022,6 +2049,7 @@ MODULE_DEVICE_TABLE(of, of_pwrap_match_tbl);
> > static int pwrap_probe(struct platform_device *pdev)
> > {
> > int ret, irq;
> > + u32 mask_done;
> > struct pmic_wrapper *wrp;
> > struct device_node *np = pdev->dev.of_node;
> > const struct of_device_id *of_slave_id = NULL;
> > @@ -2116,14 +2144,21 @@ static int pwrap_probe(struct platform_device *pdev)
> > }
> > }
> >
> > - if (!(pwrap_readl(wrp, PWRAP_WACS2_RDATA) & PWRAP_STATE_INIT_DONE0)) {
> > + if (HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + mask_done = PWRAP_STATE_INIT_DONE1;
> > + else
> > + mask_done = PWRAP_STATE_INIT_DONE0;
> > +
> > + if (!(pwrap_readl(wrp, PWRAP_WACS2_RDATA) & mask_done)) {
> > dev_dbg(wrp->dev, "initialization isn't finished\n");
> > ret = -ENODEV;
> > goto err_out2;
> > }
> >
> > /* Initialize watchdog, may not be done by the bootloader */
> > - pwrap_writel(wrp, 0xf, PWRAP_WDT_UNIT);
> > + if (!HAS_CAP(wrp->master->caps, PWRAP_CAP_ARB))
> > + pwrap_writel(wrp, 0xf, PWRAP_WDT_UNIT);
> > +
>
> Whats the connection between an arbiter being present and the watchdog?
>
Thanks for reviewing.
The arbiter capability uses new design of pwrap.
This design cannot change the watch dog timer, So I add it here.
Is it better to use another capability to define it?
> Regards,
> Matthias
next prev parent reply other threads:[~2020-11-18 11:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 11:03 [PATCH v3 0/4] Add PMIC wrapper support for Mediatek MT6873/8192 SoC IC Hsin-Hsiung Wang
2020-09-21 11:03 ` [PATCH v3 1/4] soc: mediatek: pwrap: use BIT() macro Hsin-Hsiung Wang
2020-09-21 11:03 ` [PATCH v3 2/4] soc: mediatek: pwrap: add arbiter capability Hsin-Hsiung Wang
2020-09-21 16:48 ` Matthias Brugger
2020-11-18 11:40 ` Hsin-Hsiung Wang [this message]
2020-09-21 11:03 ` [PATCH v3 3/4] dt-bindings: mediatek: add compatible for MT6873/8192 pwrap Hsin-Hsiung Wang
2020-09-21 11:03 ` [PATCH v3 4/4] soc: mediatek: pwrap: add pwrap driver for MT6873/8192 SoCs Hsin-Hsiung Wang
2020-09-22 9:49 ` Fei Shao
2020-11-18 11:42 ` Hsin-Hsiung Wang
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=1605699658.24420.3.camel@mtksdaap41 \
--to=hsin-hsiung.wang@mediatek.com \
--cc=argus.lin@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=drinkcat@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@kernel.org \
--cc=srv_heupstream@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).