From: Sean Wang <sean.wang@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: <robh+dt@kernel.org>, <mark.rutland@arm.com>,
<marcel@holtmann.org>, <johan.hedberg@gmail.com>,
<devicetree@vger.kernel.org>, <linux-bluetooth@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
"Ulf Hansson" <ulf.hansson@linaro.org>,
Weiyi Lu <weiyi.lu@mediatek.com>
Subject: Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable
Date: Fri, 20 Apr 2018 11:49:50 +0800 [thread overview]
Message-ID: <1524196190.26454.3.camel@mtkswgap22> (raw)
In-Reply-To: <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com>
On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote:
>
> On 04/03/2018 09:15 AM, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes
> > stable, which is not like the behavior the other power domains should
> > have. Therefore, it's necessary for such a power domain to have a fixed
> > and well-predefined duration to wait until its managed SRAM can be allowed
> > to access by all functions running on the top.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Weiyi Lu <weiyi.lu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index f9b7248..19aceb8 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -121,6 +121,7 @@ struct scp_domain_data {
> > u32 bus_prot_mask;
> > enum clk_id clk_id[MAX_CLKS];
> > bool active_wakeup;
> > + u32 us_sram_fwait;
>
> Before adding more and more fields to scp_domain_data which get checked in if's,
> I'd prefer to add a caps field used for bus_prot_mask, active_wakeup in a first
> patch and add the cap FORCE_WAIT in a second patch.
>
> Can you help to implement this Sean, or shall I give it a try?
>
Sure, I have a willing to do and then see if you're also fond of it.
thanks!
> Regards,
> Matthias
>
> > };
> >
> > struct scp;
> > @@ -234,11 +235,16 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> > val &= ~scpd->data->sram_pdn_bits;
> > writel(val, ctl_addr);
> >
> > - /* wait until SRAM_PDN_ACK all 0 */
> > - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > - if (ret < 0)
> > - goto err_pwr_ack;
> > + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> > + if (!scpd->data->us_sram_fwait) {
> > + ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > + if (ret < 0)
> > + goto err_pwr_ack;
> > + } else {
> > + usleep_range(scpd->data->us_sram_fwait,
> > + scpd->data->us_sram_fwait + 100);
> > + };
> >
> > if (scpd->data->bus_prot_mask) {
> > ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> > @@ -783,6 +789,7 @@ static const struct scp_domain_data scp_domain_data_mt7622[] = {
> > .clk_id = {CLK_NONE},
> > .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
> > .active_wakeup = true,
> > + .us_sram_fwait = 12000,
> > },
> > };
> >
> >
WARNING: multiple messages have this Message-ID (diff)
From: Sean Wang <sean.wang@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: robh+dt@kernel.org, mark.rutland@arm.com, marcel@holtmann.org,
johan.hedberg@gmail.com, devicetree@vger.kernel.org,
linux-bluetooth@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Ulf Hansson <ulf.hansson@linaro.org>,
Weiyi Lu <weiyi.lu@mediatek.com>
Subject: Re: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable
Date: Fri, 20 Apr 2018 11:49:50 +0800 [thread overview]
Message-ID: <1524196190.26454.3.camel@mtkswgap22> (raw)
In-Reply-To: <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com>
On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote:
>
> On 04/03/2018 09:15 AM, sean.wang@mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes
> > stable, which is not like the behavior the other power domains should
> > have. Therefore, it's necessary for such a power domain to have a fixed
> > and well-predefined duration to wait until its managed SRAM can be allowed
> > to access by all functions running on the top.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Weiyi Lu <weiyi.lu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index f9b7248..19aceb8 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -121,6 +121,7 @@ struct scp_domain_data {
> > u32 bus_prot_mask;
> > enum clk_id clk_id[MAX_CLKS];
> > bool active_wakeup;
> > + u32 us_sram_fwait;
>
> Before adding more and more fields to scp_domain_data which get checked in if's,
> I'd prefer to add a caps field used for bus_prot_mask, active_wakeup in a first
> patch and add the cap FORCE_WAIT in a second patch.
>
> Can you help to implement this Sean, or shall I give it a try?
>
Sure, I have a willing to do and then see if you're also fond of it.
thanks!
> Regards,
> Matthias
>
> > };
> >
> > struct scp;
> > @@ -234,11 +235,16 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> > val &= ~scpd->data->sram_pdn_bits;
> > writel(val, ctl_addr);
> >
> > - /* wait until SRAM_PDN_ACK all 0 */
> > - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > - if (ret < 0)
> > - goto err_pwr_ack;
> > + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> > + if (!scpd->data->us_sram_fwait) {
> > + ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > + if (ret < 0)
> > + goto err_pwr_ack;
> > + } else {
> > + usleep_range(scpd->data->us_sram_fwait,
> > + scpd->data->us_sram_fwait + 100);
> > + };
> >
> > if (scpd->data->bus_prot_mask) {
> > ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> > @@ -783,6 +789,7 @@ static const struct scp_domain_data scp_domain_data_mt7622[] = {
> > .clk_id = {CLK_NONE},
> > .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
> > .active_wakeup = true,
> > + .us_sram_fwait = 12000,
> > },
> > };
> >
> >
WARNING: multiple messages have this Message-ID (diff)
From: sean.wang@mediatek.com (Sean Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable
Date: Fri, 20 Apr 2018 11:49:50 +0800 [thread overview]
Message-ID: <1524196190.26454.3.camel@mtkswgap22> (raw)
In-Reply-To: <5f2530a0-aee2-39fe-eb5c-56cd4a68c9db@gmail.com>
On Thu, 2018-04-19 at 12:33 +0200, Matthias Brugger wrote:
>
> On 04/03/2018 09:15 AM, sean.wang at mediatek.com wrote:
> > From: Sean Wang <sean.wang@mediatek.com>
> >
> > MT7622_POWER_DOMAIN_WB doesn't send an ACK when its managed SRAM becomes
> > stable, which is not like the behavior the other power domains should
> > have. Therefore, it's necessary for such a power domain to have a fixed
> > and well-predefined duration to wait until its managed SRAM can be allowed
> > to access by all functions running on the top.
> >
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > Cc: Matthias Brugger <matthias.bgg@gmail.com>
> > Cc: Ulf Hansson <ulf.hansson@linaro.org>
> > Cc: Weiyi Lu <weiyi.lu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 17 ++++++++++++-----
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c b/drivers/soc/mediatek/mtk-scpsys.c
> > index f9b7248..19aceb8 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -121,6 +121,7 @@ struct scp_domain_data {
> > u32 bus_prot_mask;
> > enum clk_id clk_id[MAX_CLKS];
> > bool active_wakeup;
> > + u32 us_sram_fwait;
>
> Before adding more and more fields to scp_domain_data which get checked in if's,
> I'd prefer to add a caps field used for bus_prot_mask, active_wakeup in a first
> patch and add the cap FORCE_WAIT in a second patch.
>
> Can you help to implement this Sean, or shall I give it a try?
>
Sure, I have a willing to do and then see if you're also fond of it.
thanks!
> Regards,
> Matthias
>
> > };
> >
> > struct scp;
> > @@ -234,11 +235,16 @@ static int scpsys_power_on(struct generic_pm_domain *genpd)
> > val &= ~scpd->data->sram_pdn_bits;
> > writel(val, ctl_addr);
> >
> > - /* wait until SRAM_PDN_ACK all 0 */
> > - ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > - MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > - if (ret < 0)
> > - goto err_pwr_ack;
> > + /* Either wait until SRAM_PDN_ACK all 0 or have a force wait */
> > + if (!scpd->data->us_sram_fwait) {
> > + ret = readl_poll_timeout(ctl_addr, tmp, (tmp & pdn_ack) == 0,
> > + MTK_POLL_DELAY_US, MTK_POLL_TIMEOUT);
> > + if (ret < 0)
> > + goto err_pwr_ack;
> > + } else {
> > + usleep_range(scpd->data->us_sram_fwait,
> > + scpd->data->us_sram_fwait + 100);
> > + };
> >
> > if (scpd->data->bus_prot_mask) {
> > ret = mtk_infracfg_clear_bus_protection(scp->infracfg,
> > @@ -783,6 +789,7 @@ static const struct scp_domain_data scp_domain_data_mt7622[] = {
> > .clk_id = {CLK_NONE},
> > .bus_prot_mask = MT7622_TOP_AXI_PROT_EN_WB,
> > .active_wakeup = true,
> > + .us_sram_fwait = 12000,
> > },
> > };
> >
> >
next prev parent reply other threads:[~2018-04-20 3:49 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-03 7:15 [PATCH v1 0/7] add support for Bluetooth on MT7622 SoC sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-03 7:15 ` [PATCH v1 1/7] dt-bindings: net: bluetooth: Add mediatek-bluetooth sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-09 21:16 ` Rob Herring
2018-04-09 21:16 ` Rob Herring
2018-04-03 7:15 ` [PATCH v1 2/7] serdev: add dev_pm_domain_attach|detach() sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-03 10:29 ` Marcel Holtmann
2018-04-03 10:29 ` Marcel Holtmann
2018-04-26 5:29 ` Sean Wang
2018-04-26 5:29 ` Sean Wang
2018-04-26 5:29 ` Sean Wang
2018-04-03 7:15 ` [PATCH v1 3/7] soc: mediatek: reuse read[l,x]_poll_timeout helpers sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-18 15:06 ` Matthias Brugger
2018-04-18 15:06 ` Matthias Brugger
2018-04-03 7:15 ` [PATCH v1 4/7] soc: mediatek: reuse regmap_read_poll_timeout helpers sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-19 10:23 ` Matthias Brugger
2018-04-19 10:23 ` Matthias Brugger
2018-04-20 3:42 ` Sean Wang
2018-04-20 3:42 ` Sean Wang
2018-04-20 3:42 ` Sean Wang
2018-04-03 7:15 ` [PATCH v1 5/7] soc: mediatek: add a fixed wait for SRAM stable sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-05 16:42 ` Sasha Levin
2018-04-05 16:42 ` Sasha Levin
2018-04-19 10:33 ` Matthias Brugger
2018-04-19 10:33 ` Matthias Brugger
2018-04-20 3:49 ` Sean Wang [this message]
2018-04-20 3:49 ` Sean Wang
2018-04-20 3:49 ` Sean Wang
2018-04-23 8:58 ` Sean Wang
2018-04-23 8:58 ` Sean Wang
2018-04-23 8:58 ` Sean Wang
2018-04-03 7:15 ` [PATCH v1 6/7] Bluetooth: hci_mediatek: Add protocol support for MediaTek serial devices sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.wang
2018-04-03 10:27 ` Marcel Holtmann
2018-04-03 10:27 ` Marcel Holtmann
2018-04-26 7:34 ` Sean Wang
2018-04-26 7:34 ` Sean Wang
2018-04-26 7:34 ` Sean Wang
2018-04-26 9:47 ` Marcel Holtmann
2018-04-26 9:47 ` Marcel Holtmann
2018-04-27 4:13 ` Sean Wang
2018-04-27 4:13 ` Sean Wang
2018-04-27 4:13 ` Sean Wang
2018-04-27 5:25 ` Marcel Holtmann
2018-04-27 5:25 ` Marcel Holtmann
2018-04-27 9:14 ` Sean Wang
2018-04-27 9:14 ` Sean Wang
2018-04-27 9:14 ` Sean Wang
2018-04-27 16:34 ` Marcel Holtmann
2018-04-27 16:34 ` Marcel Holtmann
2018-05-08 6:48 ` Sean Wang
2018-05-08 6:48 ` Sean Wang
2018-05-08 6:48 ` Sean Wang
2018-05-08 7:27 ` Marcel Holtmann
2018-05-08 7:27 ` Marcel Holtmann
2018-05-08 8:22 ` Sean Wang
2018-05-08 8:22 ` Sean Wang
2018-05-08 8:22 ` Sean Wang
2018-05-08 11:18 ` Marcel Holtmann
2018-05-08 11:18 ` Marcel Holtmann
2018-05-10 6:45 ` Sean Wang
2018-05-10 6:45 ` Sean Wang
2018-05-10 6:45 ` Sean Wang
2018-04-03 12:13 ` kbuild test robot
2018-04-03 12:13 ` kbuild test robot
2018-04-03 12:13 ` kbuild test robot
2018-04-03 12:13 ` [RFC PATCH] Bluetooth: hci_mediatek: mtk_recv_frame() can be static kbuild test robot
2018-04-03 12:13 ` kbuild test robot
2018-04-03 12:13 ` kbuild test robot
2018-04-03 7:15 ` [PATCH v1 7/7] MAINTAINERS: add an entry for MediaTek Bluetooth driver sean.wang
2018-04-03 7:15 ` sean.wang at mediatek.com
2018-04-03 7:15 ` sean.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=1524196190.26454.3.camel@mtkswgap22 \
--to=sean.wang@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=johan.hedberg@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=marcel@holtmann.org \
--cc=mark.rutland@arm.com \
--cc=matthias.bgg@gmail.com \
--cc=robh+dt@kernel.org \
--cc=ulf.hansson@linaro.org \
--cc=weiyi.lu@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.