From: Neal Liu <neal.liu@mediatek.com>
To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: devicetree@vger.kernel.org,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Neal Liu <neal.liu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Date: Tue, 16 Jun 2020 14:09:58 +0800 [thread overview]
Message-ID: <1592287798.18012.3.camel@mtkswgap22> (raw)
In-Reply-To: <CAAOTY_8booP95diFN=C-ybTBciqsw=B7Zq4dCS8=VOjgyUTu1A@mail.gmail.com>
Hi Chun-Kuang,
On Mon, 2020-06-15 at 22:17 +0800, Chun-Kuang Hu wrote:
> Chun-Kuang Hu <chunkuang.hu@kernel.org> 於 2020年6月15日 週一 下午10:14寫道:
> >
> > Hi, Neal:
> >
> > Neal Liu <neal.liu@mediatek.com> 於 2020年6月15日 週一 上午10:43寫道:
> > >
> > > Hi Chun-Kuang,
> > >
> > >
> > > On Sun, 2020-06-14 at 11:26 +0800, Chun-Kuang Hu wrote:
> > > > Hi, Neal:
> > > >
> > > > Neal Liu <neal.liu@mediatek.com> 於 2020年6月9日 週二 下午6:25寫道:
> > > > >
> > > > > MT6873 bus frabric provides TrustZone security support and data
> > > > > protection to prevent slaves from being accessed by unexpected
> > > > > masters.
> > > > > The security violations are logged and sent to the processor for
> > > > > further analysis or countermeasures.
> > > > >
> > > > > Any occurrence of security violation would raise an interrupt, and
> > > > > it will be handled by devapc-mt6873 driver. The violation
> > > > > information is printed in order to find the murderer.
> > > > >
> > > > > Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> > > > > ---
> > > >
> > > > [snip]
> > > >
> > > > > +
> > > > > + /* 50 */
> > > > > + {-1, -1, 50, "OOB_way_en", true},
> > > > > + {-1, -1, 51, "OOB_way_en", true},
> > > > > + {-1, -1, 52, "OOB_way_en", true},
> > > > > + {-1, -1, 53, "OOB_way_en", true},
> > > > > + {-1, -1, 54, "OOB_way_en", true},
> > > > > + {-1, -1, 55, "OOB_way_en", true},
> > > > > + {-1, -1, 56, "Decode_error", true},
> > > > > + {-1, -1, 57, "Decode_error", true},
> > > > > + {-1, -1, 58, "DISP_PWM", false},
> > > > > + {-1, -1, 59, "IMP_IIC_WRAP", false},
> > > > > +
> > > > > + /* 60 */
> > > > > + {-1, -1, 60, "DEVICE_APC_PERI_PAR__AO", false},
> > > > > + {-1, -1, 61, "DEVICE_APC_PERI_PAR_PDN", false},
> > > >
> > > > You does not process the item whose enable_vio_irq is false, so I
> > > > think you should remove these items and remove enable_vio_irq because
> > > > the rest item's enable_vio_irq would always be true.
> > >
> > > In some users, they can decide which slaves they want to enable or
> > > disable violation irq in different product. We remain this property for
> > > compatibility.
> >
> > I think in upstream version, you could still remove enable_vio_irq and
> > process all items. For downstream case, users could remove items they
> > does not interest in.
Okay, sounds good. I'll try to revise and upstream again.
> >
> > >
> > > >
> > > > > +};
> > > > > +
> > > > > +static struct mtk_device_num mtk6873_devices_num[] = {
> > > > > + {SLAVE_TYPE_INFRA, VIO_SLAVE_NUM_INFRA},
> > > > > + {SLAVE_TYPE_PERI, VIO_SLAVE_NUM_PERI},
> > > > > + {SLAVE_TYPE_PERI2, VIO_SLAVE_NUM_PERI2},
> > > > > + {SLAVE_TYPE_PERI_PAR, VIO_SLAVE_NUM_PERI_PAR},
> > > > > +};
> > > > > +
> > > > > +static struct PERIAXI_ID_INFO peri_mi_id_to_master[] = {
> > > > > + {"THERM2", { 0, 0, 0 } },
> > > > > + {"SPM", { 0, 1, 0 } },
> > > > > + {"CCU", { 0, 0, 1 } },
> > > > > + {"THERM", { 0, 1, 1 } },
> > > > > + {"SPM_DRAMC", { 1, 1, 0 } },
> > > >
> > > > The bits { 1, 1, 0 } equal to a number 0x3, I thiink you should use a
> > > > number instead of bits and everything would be more easy.
> > >
> > > We would like to keep it because the bit value contains more than 0/1,
> > > it might be '2' in some cases. '2' means it can be 0 or 1. This totally
> > > by hardware design & implementation.
> >
> > Upstream the patch that has dont-care-bits, otherwise, use a number for this.
> > Even there is dont-care-bits, I have a better way to process it. Here
> > is an example that has dont-care-bits:
> >
> > + {"Tinysys", { 0, 1, 0, 0, 2, 2, 2, 2, 2, 2, 0, 0, 0, 0 } },
> >
> > I could use a { value, mask } pair for this case,
> >
> > value = 0x0002; /* value for care bits */
> > mask = 0x3c02; /* mask for care bits */
>
> Sorry, this would be
>
> mask = 0x3c0f; /* mask for care bits */
>
> >
> > So the compare statement would be
> >
> > if ((bus_id & mask) == value)
> >
> > So you could get rid of the second for-loop and reduce the processing
> > time in irq handler.
> >
Great idea! I'll try to revise and upstream again.
> > Regards,
> > Chun-Kuang.
_______________________________________________
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: Neal Liu <neal.liu@mediatek.com>
To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: devicetree@vger.kernel.org,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Neal Liu <neal.liu@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Date: Tue, 16 Jun 2020 14:09:58 +0800 [thread overview]
Message-ID: <1592287798.18012.3.camel@mtkswgap22> (raw)
In-Reply-To: <CAAOTY_8booP95diFN=C-ybTBciqsw=B7Zq4dCS8=VOjgyUTu1A@mail.gmail.com>
Hi Chun-Kuang,
On Mon, 2020-06-15 at 22:17 +0800, Chun-Kuang Hu wrote:
> Chun-Kuang Hu <chunkuang.hu@kernel.org> 於 2020年6月15日 週一 下午10:14寫道:
> >
> > Hi, Neal:
> >
> > Neal Liu <neal.liu@mediatek.com> 於 2020年6月15日 週一 上午10:43寫道:
> > >
> > > Hi Chun-Kuang,
> > >
> > >
> > > On Sun, 2020-06-14 at 11:26 +0800, Chun-Kuang Hu wrote:
> > > > Hi, Neal:
> > > >
> > > > Neal Liu <neal.liu@mediatek.com> 於 2020年6月9日 週二 下午6:25寫道:
> > > > >
> > > > > MT6873 bus frabric provides TrustZone security support and data
> > > > > protection to prevent slaves from being accessed by unexpected
> > > > > masters.
> > > > > The security violations are logged and sent to the processor for
> > > > > further analysis or countermeasures.
> > > > >
> > > > > Any occurrence of security violation would raise an interrupt, and
> > > > > it will be handled by devapc-mt6873 driver. The violation
> > > > > information is printed in order to find the murderer.
> > > > >
> > > > > Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> > > > > ---
> > > >
> > > > [snip]
> > > >
> > > > > +
> > > > > + /* 50 */
> > > > > + {-1, -1, 50, "OOB_way_en", true},
> > > > > + {-1, -1, 51, "OOB_way_en", true},
> > > > > + {-1, -1, 52, "OOB_way_en", true},
> > > > > + {-1, -1, 53, "OOB_way_en", true},
> > > > > + {-1, -1, 54, "OOB_way_en", true},
> > > > > + {-1, -1, 55, "OOB_way_en", true},
> > > > > + {-1, -1, 56, "Decode_error", true},
> > > > > + {-1, -1, 57, "Decode_error", true},
> > > > > + {-1, -1, 58, "DISP_PWM", false},
> > > > > + {-1, -1, 59, "IMP_IIC_WRAP", false},
> > > > > +
> > > > > + /* 60 */
> > > > > + {-1, -1, 60, "DEVICE_APC_PERI_PAR__AO", false},
> > > > > + {-1, -1, 61, "DEVICE_APC_PERI_PAR_PDN", false},
> > > >
> > > > You does not process the item whose enable_vio_irq is false, so I
> > > > think you should remove these items and remove enable_vio_irq because
> > > > the rest item's enable_vio_irq would always be true.
> > >
> > > In some users, they can decide which slaves they want to enable or
> > > disable violation irq in different product. We remain this property for
> > > compatibility.
> >
> > I think in upstream version, you could still remove enable_vio_irq and
> > process all items. For downstream case, users could remove items they
> > does not interest in.
Okay, sounds good. I'll try to revise and upstream again.
> >
> > >
> > > >
> > > > > +};
> > > > > +
> > > > > +static struct mtk_device_num mtk6873_devices_num[] = {
> > > > > + {SLAVE_TYPE_INFRA, VIO_SLAVE_NUM_INFRA},
> > > > > + {SLAVE_TYPE_PERI, VIO_SLAVE_NUM_PERI},
> > > > > + {SLAVE_TYPE_PERI2, VIO_SLAVE_NUM_PERI2},
> > > > > + {SLAVE_TYPE_PERI_PAR, VIO_SLAVE_NUM_PERI_PAR},
> > > > > +};
> > > > > +
> > > > > +static struct PERIAXI_ID_INFO peri_mi_id_to_master[] = {
> > > > > + {"THERM2", { 0, 0, 0 } },
> > > > > + {"SPM", { 0, 1, 0 } },
> > > > > + {"CCU", { 0, 0, 1 } },
> > > > > + {"THERM", { 0, 1, 1 } },
> > > > > + {"SPM_DRAMC", { 1, 1, 0 } },
> > > >
> > > > The bits { 1, 1, 0 } equal to a number 0x3, I thiink you should use a
> > > > number instead of bits and everything would be more easy.
> > >
> > > We would like to keep it because the bit value contains more than 0/1,
> > > it might be '2' in some cases. '2' means it can be 0 or 1. This totally
> > > by hardware design & implementation.
> >
> > Upstream the patch that has dont-care-bits, otherwise, use a number for this.
> > Even there is dont-care-bits, I have a better way to process it. Here
> > is an example that has dont-care-bits:
> >
> > + {"Tinysys", { 0, 1, 0, 0, 2, 2, 2, 2, 2, 2, 0, 0, 0, 0 } },
> >
> > I could use a { value, mask } pair for this case,
> >
> > value = 0x0002; /* value for care bits */
> > mask = 0x3c02; /* mask for care bits */
>
> Sorry, this would be
>
> mask = 0x3c0f; /* mask for care bits */
>
> >
> > So the compare statement would be
> >
> > if ((bus_id & mask) == value)
> >
> > So you could get rid of the second for-loop and reduce the processing
> > time in irq handler.
> >
Great idea! I'll try to revise and upstream again.
> > Regards,
> > Chun-Kuang.
_______________________________________________
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: Neal Liu <neal.liu@mediatek.com>
To: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Cc: Neal Liu <neal.liu@mediatek.com>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
<devicetree@vger.kernel.org>,
wsd_upstream <wsd_upstream@mediatek.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@lists.infradead.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Date: Tue, 16 Jun 2020 14:09:58 +0800 [thread overview]
Message-ID: <1592287798.18012.3.camel@mtkswgap22> (raw)
In-Reply-To: <CAAOTY_8booP95diFN=C-ybTBciqsw=B7Zq4dCS8=VOjgyUTu1A@mail.gmail.com>
Hi Chun-Kuang,
On Mon, 2020-06-15 at 22:17 +0800, Chun-Kuang Hu wrote:
> Chun-Kuang Hu <chunkuang.hu@kernel.org> 於 2020年6月15日 週一 下午10:14寫道:
> >
> > Hi, Neal:
> >
> > Neal Liu <neal.liu@mediatek.com> 於 2020年6月15日 週一 上午10:43寫道:
> > >
> > > Hi Chun-Kuang,
> > >
> > >
> > > On Sun, 2020-06-14 at 11:26 +0800, Chun-Kuang Hu wrote:
> > > > Hi, Neal:
> > > >
> > > > Neal Liu <neal.liu@mediatek.com> 於 2020年6月9日 週二 下午6:25寫道:
> > > > >
> > > > > MT6873 bus frabric provides TrustZone security support and data
> > > > > protection to prevent slaves from being accessed by unexpected
> > > > > masters.
> > > > > The security violations are logged and sent to the processor for
> > > > > further analysis or countermeasures.
> > > > >
> > > > > Any occurrence of security violation would raise an interrupt, and
> > > > > it will be handled by devapc-mt6873 driver. The violation
> > > > > information is printed in order to find the murderer.
> > > > >
> > > > > Signed-off-by: Neal Liu <neal.liu@mediatek.com>
> > > > > ---
> > > >
> > > > [snip]
> > > >
> > > > > +
> > > > > + /* 50 */
> > > > > + {-1, -1, 50, "OOB_way_en", true},
> > > > > + {-1, -1, 51, "OOB_way_en", true},
> > > > > + {-1, -1, 52, "OOB_way_en", true},
> > > > > + {-1, -1, 53, "OOB_way_en", true},
> > > > > + {-1, -1, 54, "OOB_way_en", true},
> > > > > + {-1, -1, 55, "OOB_way_en", true},
> > > > > + {-1, -1, 56, "Decode_error", true},
> > > > > + {-1, -1, 57, "Decode_error", true},
> > > > > + {-1, -1, 58, "DISP_PWM", false},
> > > > > + {-1, -1, 59, "IMP_IIC_WRAP", false},
> > > > > +
> > > > > + /* 60 */
> > > > > + {-1, -1, 60, "DEVICE_APC_PERI_PAR__AO", false},
> > > > > + {-1, -1, 61, "DEVICE_APC_PERI_PAR_PDN", false},
> > > >
> > > > You does not process the item whose enable_vio_irq is false, so I
> > > > think you should remove these items and remove enable_vio_irq because
> > > > the rest item's enable_vio_irq would always be true.
> > >
> > > In some users, they can decide which slaves they want to enable or
> > > disable violation irq in different product. We remain this property for
> > > compatibility.
> >
> > I think in upstream version, you could still remove enable_vio_irq and
> > process all items. For downstream case, users could remove items they
> > does not interest in.
Okay, sounds good. I'll try to revise and upstream again.
> >
> > >
> > > >
> > > > > +};
> > > > > +
> > > > > +static struct mtk_device_num mtk6873_devices_num[] = {
> > > > > + {SLAVE_TYPE_INFRA, VIO_SLAVE_NUM_INFRA},
> > > > > + {SLAVE_TYPE_PERI, VIO_SLAVE_NUM_PERI},
> > > > > + {SLAVE_TYPE_PERI2, VIO_SLAVE_NUM_PERI2},
> > > > > + {SLAVE_TYPE_PERI_PAR, VIO_SLAVE_NUM_PERI_PAR},
> > > > > +};
> > > > > +
> > > > > +static struct PERIAXI_ID_INFO peri_mi_id_to_master[] = {
> > > > > + {"THERM2", { 0, 0, 0 } },
> > > > > + {"SPM", { 0, 1, 0 } },
> > > > > + {"CCU", { 0, 0, 1 } },
> > > > > + {"THERM", { 0, 1, 1 } },
> > > > > + {"SPM_DRAMC", { 1, 1, 0 } },
> > > >
> > > > The bits { 1, 1, 0 } equal to a number 0x3, I thiink you should use a
> > > > number instead of bits and everything would be more easy.
> > >
> > > We would like to keep it because the bit value contains more than 0/1,
> > > it might be '2' in some cases. '2' means it can be 0 or 1. This totally
> > > by hardware design & implementation.
> >
> > Upstream the patch that has dont-care-bits, otherwise, use a number for this.
> > Even there is dont-care-bits, I have a better way to process it. Here
> > is an example that has dont-care-bits:
> >
> > + {"Tinysys", { 0, 1, 0, 0, 2, 2, 2, 2, 2, 2, 0, 0, 0, 0 } },
> >
> > I could use a { value, mask } pair for this case,
> >
> > value = 0x0002; /* value for care bits */
> > mask = 0x3c02; /* mask for care bits */
>
> Sorry, this would be
>
> mask = 0x3c0f; /* mask for care bits */
>
> >
> > So the compare statement would be
> >
> > if ((bus_id & mask) == value)
> >
> > So you could get rid of the second for-loop and reduce the processing
> > time in irq handler.
> >
Great idea! I'll try to revise and upstream again.
> > Regards,
> > Chun-Kuang.
next prev parent reply other threads:[~2020-06-16 6:10 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-09 10:24 Add MediaTek MT6873 devapc driver Neal Liu
2020-06-09 10:24 ` Neal Liu
2020-06-09 10:24 ` Neal Liu
2020-06-09 10:24 ` [PATCH 1/2] dt-bindings: devapc: add bindings for devapc-mt6873 Neal Liu
2020-06-09 10:24 ` Neal Liu
2020-06-09 10:24 ` Neal Liu
2020-06-09 17:27 ` Rob Herring
2020-06-09 17:27 ` Rob Herring
2020-06-09 17:27 ` Rob Herring
2020-06-09 10:24 ` [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver Neal Liu
2020-06-09 10:24 ` Neal Liu
2020-06-09 16:01 ` Chun-Kuang Hu
2020-06-09 16:01 ` Chun-Kuang Hu
2020-06-09 16:01 ` Chun-Kuang Hu
2020-06-11 9:26 ` Neal Liu
2020-06-11 9:26 ` Neal Liu
2020-06-11 9:26 ` Neal Liu
2020-06-11 11:01 ` Chun-Kuang Hu
2020-06-11 11:01 ` Chun-Kuang Hu
2020-06-11 11:01 ` Chun-Kuang Hu
2020-06-12 3:04 ` Neal Liu
2020-06-12 3:04 ` Neal Liu
2020-06-12 3:04 ` Neal Liu
2020-06-12 15:27 ` Chun-Kuang Hu
2020-06-12 15:27 ` Chun-Kuang Hu
2020-06-12 15:27 ` Chun-Kuang Hu
2020-06-15 2:12 ` Neal Liu
2020-06-15 2:12 ` Neal Liu
2020-06-15 2:12 ` Neal Liu
2020-06-12 23:20 ` Chun-Kuang Hu
2020-06-12 23:20 ` Chun-Kuang Hu
2020-06-12 23:20 ` Chun-Kuang Hu
2020-06-16 6:45 ` Neal Liu
2020-06-16 6:45 ` Neal Liu
2020-06-16 6:45 ` Neal Liu
2020-06-14 3:26 ` Chun-Kuang Hu
2020-06-14 3:26 ` Chun-Kuang Hu
2020-06-14 3:26 ` Chun-Kuang Hu
2020-06-15 2:43 ` Neal Liu
2020-06-15 2:43 ` Neal Liu
2020-06-15 2:43 ` Neal Liu
2020-06-15 14:14 ` Chun-Kuang Hu
2020-06-15 14:14 ` Chun-Kuang Hu
2020-06-15 14:14 ` Chun-Kuang Hu
2020-06-15 14:17 ` Chun-Kuang Hu
2020-06-15 14:17 ` Chun-Kuang Hu
2020-06-15 14:17 ` Chun-Kuang Hu
2020-06-16 6:09 ` Neal Liu [this message]
2020-06-16 6:09 ` Neal Liu
2020-06-16 6:09 ` Neal Liu
2020-06-15 15:51 ` Chun-Kuang Hu
2020-06-15 15:51 ` Chun-Kuang Hu
2020-06-15 15:51 ` Chun-Kuang Hu
2020-06-16 6:19 ` Neal Liu
2020-06-16 6:19 ` Neal Liu
2020-06-16 6:19 ` Neal Liu
2020-06-09 17:32 ` Add MediaTek MT6873 devapc driver Rob Herring
2020-06-09 17:32 ` Rob Herring
2020-06-09 17:32 ` Rob Herring
2020-06-24 3:51 ` Neal Liu
2020-06-24 3:51 ` Neal Liu
2020-06-24 3:51 ` Neal Liu
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=1592287798.18012.3.camel@mtkswgap22 \
--to=neal.liu@mediatek.com \
--cc=chunkuang.hu@kernel.org \
--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=robh+dt@kernel.org \
--cc=wsd_upstream@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.