From: Nina Wu <nina-cm.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Zhen Lei <thunder.leizhen@huawei.com>,
Neal Liu <neal.liu@mediatek.com>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>, <Jackson-kt.Chang@mediatek.com>
Subject: Re: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for new IC support
Date: Thu, 8 Apr 2021 14:09:28 +0800 [thread overview]
Message-ID: <1617862168.8874.13.camel@mtksdccf07> (raw)
In-Reply-To: <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>
Hi, Matthias
On Tue, 2021-04-06 at 15:53 +0200, Matthias Brugger wrote:
>
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu@mediatek.com>
> >
> > There are 3 debug info registers in new ICs while in legacy ones,
> > we have only 2. When dumping the debug info, we need to check first
> > if the 3rd debug register exists and then we can konw how to decipher
> > the debug info.
> >
> > Signed-off-by: Nina Wu <Nina-CM.Wu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index bcf6e3c..af55c01 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
> > u32 addr_h:4;
> > u32 resv:4;
> > } dbg0_bits;
> > +
> > + /* Not used, reference only */
> > + struct {
> > + u32 dmnid:6;
> > + u32 vio_w:1;
> > + u32 vio_r:1;
> > + u32 addr_h:4;
> > + u32 resv:20;
> > + } dbg0_bits_ver2;
> > };
> >
> > u32 vio_dbg1;
> > + u32 vio_dbg2;
> > };
> >
> > struct mtk_devapc_data {
> > @@ -37,6 +47,7 @@ struct mtk_devapc_data {
> > u32 vio_sta_offset;
> > u32 vio_dbg0_offset;
> > u32 vio_dbg1_offset;
> > + u32 vio_dbg2_offset;
> > u32 apc_con_offset;
> > u32 vio_shift_sta_offset;
> > u32 vio_shift_sel_offset;
> > @@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > struct mtk_devapc_vio_dbgs vio_dbgs;
> > void __iomem *vio_dbg0_reg;
> > void __iomem *vio_dbg1_reg;
> > + void __iomem *vio_dbg2_reg;
> > + u32 vio_addr, bus_id;
> >
> > vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> > vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> > + vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
>
> We should read this only if we have version2 of the devapc.
>
You're right.
It is not good to read vio_dbg2_reg in version one. Even though we will
only get the value from offset 0 (which is not expected) instead of
doing any real harm. (like causing bus hang)
> >
> > vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
> > vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> > + vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
> > +
> > + if (!ctx->data->vio_dbg2_offset) {
>
> I think we should add a version field to mtk_devapc_data to distinguish the two
> of them.
OK.
I will try to add this field in the next version
>
> > + /* arch version 1 */
> > + bus_id = vio_dbgs.dbg0_bits.mstid;
> > + vio_addr = vio_dbgs.vio_dbg1;
> > + } else {
> > + /* arch version 2 */
> > + bus_id = vio_dbgs.vio_dbg1;
> > + vio_addr = vio_dbgs.vio_dbg2;
> > +
> > + /* To align with the bit definition of arch_ver 1 */
> > + vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);
>
> That's magic, better add another variable domain_id and do here:
> domain_id = vio_dgbs.dbg0_bits_ver2.dmnid;
>
OK.
I will fix it up in the next version.
Thanks
> > + }
> >
> > /* Print violation information */
> > if (vio_dbgs.dbg0_bits.vio_w)
> > @@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > dev_info(ctx->dev, "Read Violation\n");
> >
> > dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
> > - vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
> > - vio_dbgs.vio_dbg1);
> > + bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
> > }
> >
> > /*
> >
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
WARNING: multiple messages have this Message-ID (diff)
From: Nina Wu <nina-cm.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Zhen Lei <thunder.leizhen@huawei.com>,
Neal Liu <neal.liu@mediatek.com>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>, <Jackson-kt.Chang@mediatek.com>
Subject: Re: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for new IC support
Date: Thu, 8 Apr 2021 14:09:28 +0800 [thread overview]
Message-ID: <1617862168.8874.13.camel@mtksdccf07> (raw)
In-Reply-To: <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>
Hi, Matthias
On Tue, 2021-04-06 at 15:53 +0200, Matthias Brugger wrote:
>
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu@mediatek.com>
> >
> > There are 3 debug info registers in new ICs while in legacy ones,
> > we have only 2. When dumping the debug info, we need to check first
> > if the 3rd debug register exists and then we can konw how to decipher
> > the debug info.
> >
> > Signed-off-by: Nina Wu <Nina-CM.Wu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index bcf6e3c..af55c01 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
> > u32 addr_h:4;
> > u32 resv:4;
> > } dbg0_bits;
> > +
> > + /* Not used, reference only */
> > + struct {
> > + u32 dmnid:6;
> > + u32 vio_w:1;
> > + u32 vio_r:1;
> > + u32 addr_h:4;
> > + u32 resv:20;
> > + } dbg0_bits_ver2;
> > };
> >
> > u32 vio_dbg1;
> > + u32 vio_dbg2;
> > };
> >
> > struct mtk_devapc_data {
> > @@ -37,6 +47,7 @@ struct mtk_devapc_data {
> > u32 vio_sta_offset;
> > u32 vio_dbg0_offset;
> > u32 vio_dbg1_offset;
> > + u32 vio_dbg2_offset;
> > u32 apc_con_offset;
> > u32 vio_shift_sta_offset;
> > u32 vio_shift_sel_offset;
> > @@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > struct mtk_devapc_vio_dbgs vio_dbgs;
> > void __iomem *vio_dbg0_reg;
> > void __iomem *vio_dbg1_reg;
> > + void __iomem *vio_dbg2_reg;
> > + u32 vio_addr, bus_id;
> >
> > vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> > vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> > + vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
>
> We should read this only if we have version2 of the devapc.
>
You're right.
It is not good to read vio_dbg2_reg in version one. Even though we will
only get the value from offset 0 (which is not expected) instead of
doing any real harm. (like causing bus hang)
> >
> > vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
> > vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> > + vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
> > +
> > + if (!ctx->data->vio_dbg2_offset) {
>
> I think we should add a version field to mtk_devapc_data to distinguish the two
> of them.
OK.
I will try to add this field in the next version
>
> > + /* arch version 1 */
> > + bus_id = vio_dbgs.dbg0_bits.mstid;
> > + vio_addr = vio_dbgs.vio_dbg1;
> > + } else {
> > + /* arch version 2 */
> > + bus_id = vio_dbgs.vio_dbg1;
> > + vio_addr = vio_dbgs.vio_dbg2;
> > +
> > + /* To align with the bit definition of arch_ver 1 */
> > + vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);
>
> That's magic, better add another variable domain_id and do here:
> domain_id = vio_dgbs.dbg0_bits_ver2.dmnid;
>
OK.
I will fix it up in the next version.
Thanks
> > + }
> >
> > /* Print violation information */
> > if (vio_dbgs.dbg0_bits.vio_w)
> > @@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > dev_info(ctx->dev, "Read Violation\n");
> >
> > dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
> > - vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
> > - vio_dbgs.vio_dbg1);
> > + bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
> > }
> >
> > /*
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Nina Wu <nina-cm.wu@mediatek.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>,
Zhen Lei <thunder.leizhen@huawei.com>,
Neal Liu <neal.liu@mediatek.com>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>,
<srv_heupstream@mediatek.com>, <Jackson-kt.Chang@mediatek.com>
Subject: Re: [PATCH v2 5/6] soc: mediatek: devapc: add debug register for new IC support
Date: Thu, 8 Apr 2021 14:09:28 +0800 [thread overview]
Message-ID: <1617862168.8874.13.camel@mtksdccf07> (raw)
In-Reply-To: <23c0d15c-6cc2-dc40-e45a-c2fb749cec1f@gmail.com>
Hi, Matthias
On Tue, 2021-04-06 at 15:53 +0200, Matthias Brugger wrote:
>
> On 01/04/2021 08:38, Nina Wu wrote:
> > From: Nina Wu <Nina-CM.Wu@mediatek.com>
> >
> > There are 3 debug info registers in new ICs while in legacy ones,
> > we have only 2. When dumping the debug info, we need to check first
> > if the 3rd debug register exists and then we can konw how to decipher
> > the debug info.
> >
> > Signed-off-by: Nina Wu <Nina-CM.Wu@mediatek.com>
> > ---
> > drivers/soc/mediatek/mtk-devapc.c | 31 +++++++++++++++++++++++++++++--
> > 1 file changed, 29 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/soc/mediatek/mtk-devapc.c b/drivers/soc/mediatek/mtk-devapc.c
> > index bcf6e3c..af55c01 100644
> > --- a/drivers/soc/mediatek/mtk-devapc.c
> > +++ b/drivers/soc/mediatek/mtk-devapc.c
> > @@ -26,9 +26,19 @@ struct mtk_devapc_vio_dbgs {
> > u32 addr_h:4;
> > u32 resv:4;
> > } dbg0_bits;
> > +
> > + /* Not used, reference only */
> > + struct {
> > + u32 dmnid:6;
> > + u32 vio_w:1;
> > + u32 vio_r:1;
> > + u32 addr_h:4;
> > + u32 resv:20;
> > + } dbg0_bits_ver2;
> > };
> >
> > u32 vio_dbg1;
> > + u32 vio_dbg2;
> > };
> >
> > struct mtk_devapc_data {
> > @@ -37,6 +47,7 @@ struct mtk_devapc_data {
> > u32 vio_sta_offset;
> > u32 vio_dbg0_offset;
> > u32 vio_dbg1_offset;
> > + u32 vio_dbg2_offset;
> > u32 apc_con_offset;
> > u32 vio_shift_sta_offset;
> > u32 vio_shift_sel_offset;
> > @@ -158,12 +169,29 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > struct mtk_devapc_vio_dbgs vio_dbgs;
> > void __iomem *vio_dbg0_reg;
> > void __iomem *vio_dbg1_reg;
> > + void __iomem *vio_dbg2_reg;
> > + u32 vio_addr, bus_id;
> >
> > vio_dbg0_reg = ctx->base + ctx->data->vio_dbg0_offset;
> > vio_dbg1_reg = ctx->base + ctx->data->vio_dbg1_offset;
> > + vio_dbg2_reg = ctx->base + ctx->data->vio_dbg2_offset;
>
> We should read this only if we have version2 of the devapc.
>
You're right.
It is not good to read vio_dbg2_reg in version one. Even though we will
only get the value from offset 0 (which is not expected) instead of
doing any real harm. (like causing bus hang)
> >
> > vio_dbgs.vio_dbg0 = readl(vio_dbg0_reg);
> > vio_dbgs.vio_dbg1 = readl(vio_dbg1_reg);
> > + vio_dbgs.vio_dbg2 = readl(vio_dbg2_reg);
> > +
> > + if (!ctx->data->vio_dbg2_offset) {
>
> I think we should add a version field to mtk_devapc_data to distinguish the two
> of them.
OK.
I will try to add this field in the next version
>
> > + /* arch version 1 */
> > + bus_id = vio_dbgs.dbg0_bits.mstid;
> > + vio_addr = vio_dbgs.vio_dbg1;
> > + } else {
> > + /* arch version 2 */
> > + bus_id = vio_dbgs.vio_dbg1;
> > + vio_addr = vio_dbgs.vio_dbg2;
> > +
> > + /* To align with the bit definition of arch_ver 1 */
> > + vio_dbgs.vio_dbg0 = (vio_dbgs.vio_dbg0 << 16);
>
> That's magic, better add another variable domain_id and do here:
> domain_id = vio_dgbs.dbg0_bits_ver2.dmnid;
>
OK.
I will fix it up in the next version.
Thanks
> > + }
> >
> > /* Print violation information */
> > if (vio_dbgs.dbg0_bits.vio_w)
> > @@ -172,8 +200,7 @@ static void devapc_extract_vio_dbg(struct mtk_devapc_context *ctx)
> > dev_info(ctx->dev, "Read Violation\n");
> >
> > dev_info(ctx->dev, "Bus ID:0x%x, Dom ID:0x%x, Vio Addr:0x%x\n",
> > - vio_dbgs.dbg0_bits.mstid, vio_dbgs.dbg0_bits.dmnid,
> > - vio_dbgs.vio_dbg1);
> > + bus_id, vio_dbgs.dbg0_bits.dmnid, vio_addr);
> > }
> >
> > /*
> >
next prev parent reply other threads:[~2021-04-08 6:10 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 6:38 [PATCH v2 1/6] dt-bindings: devapc: Update bindings Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` [PATCH v2 2/6] soc: mediatek: devapc: move 'vio_idx_num' info to DT Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-06 13:41 ` Matthias Brugger
2021-04-06 13:41 ` Matthias Brugger
2021-04-06 13:41 ` Matthias Brugger
2021-04-08 5:57 ` Nina Wu
2021-04-08 5:57 ` Nina Wu
2021-04-08 5:57 ` Nina Wu
2021-04-01 6:38 ` [PATCH v2 3/6] soc: mediatek: devapc: add shared flag to IRQ Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` [PATCH v2 4/6] soc: mediatek: devapc: rename variable for new IC support Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-06 13:43 ` Matthias Brugger
2021-04-06 13:43 ` Matthias Brugger
2021-04-06 13:43 ` Matthias Brugger
2021-04-08 5:58 ` Nina Wu
2021-04-08 5:58 ` Nina Wu
2021-04-08 5:58 ` Nina Wu
2021-04-01 6:38 ` [PATCH v2 5/6] soc: mediatek: devapc: add debug register " Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-06 13:53 ` Matthias Brugger
2021-04-06 13:53 ` Matthias Brugger
2021-04-06 13:53 ` Matthias Brugger
2021-04-08 6:09 ` Nina Wu [this message]
2021-04-08 6:09 ` Nina Wu
2021-04-08 6:09 ` Nina Wu
2021-04-01 6:38 ` [PATCH v2 6/6] soc: mediatek: devapc: support mt8192 Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-01 6:38 ` Nina Wu
2021-04-06 13:55 ` Matthias Brugger
2021-04-06 13:55 ` Matthias Brugger
2021-04-06 13:55 ` Matthias Brugger
2021-04-08 6:14 ` Nina Wu
2021-04-08 6:14 ` Nina Wu
2021-04-08 6:14 ` Nina Wu
2021-04-08 20:43 ` [PATCH v2 1/6] dt-bindings: devapc: Update bindings Rob Herring
2021-04-08 20:43 ` Rob Herring
2021-04-08 20:43 ` Rob Herring
2021-04-09 3:30 ` Nina Wu
2021-04-09 3:30 ` Nina Wu
2021-04-09 3:30 ` Nina Wu
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=1617862168.8874.13.camel@mtksdccf07 \
--to=nina-cm.wu@mediatek.com \
--cc=Jackson-kt.Chang@mediatek.com \
--cc=devicetree@vger.kernel.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=neal.liu@mediatek.com \
--cc=robh+dt@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=thunder.leizhen@huawei.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.