linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chun-Kuang Hu <chunkuang.hu@kernel.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: Chun-Kuang Hu <chunkuang.hu@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"moderated list:ARM/Mediatek SoC support" 
	<linux-mediatek@lists.infradead.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] soc: mediatek: devapc: add devapc-mt6873 driver
Date: Fri, 12 Jun 2020 23:27:49 +0800	[thread overview]
Message-ID: <CAAOTY__zXZvv1gcKgxnbpv2RjDLyuQ1NEz8Nr+dtn4GKE1cvMA@mail.gmail.com> (raw)
In-Reply-To: <1591931042.32738.26.camel@mtkswgap22>

Hi, Neal:

Neal Liu <neal.liu@mediatek.com> 於 2020年6月12日 週五 上午11:04寫道:
>
> Hi Chun-Kuang,
>
> [snip]
> > > > > +/*
> > > > > + * devapc_violation_irq - the devapc Interrupt Service Routine (ISR) will dump
> > > > > + *                       violation information including which master violates
> > > > > + *                       access slave.
> > > > > + */
> > > > > +static irqreturn_t devapc_violation_irq(int irq_number, void *dev_id)
> > > > > +{
> > > > > +       u32 slave_type_num = mtk_devapc_ctx->soc->slave_type_num;
> > > > > +       const struct mtk_device_info **device_info;
> > > > > +       struct mtk_devapc_vio_info *vio_info;
> > > > > +       int slave_type, vio_idx, index;
> > > > > +       const char *vio_master;
> > > > > +       unsigned long flags;
> > > > > +       bool normal;
> > > > > +       u8 perm;
> > > > > +
> > > > > +       spin_lock_irqsave(&devapc_lock, flags);
> > > > > +
> > > > > +       device_info = mtk_devapc_ctx->soc->device_info;
> > > > > +       vio_info = mtk_devapc_ctx->soc->vio_info;
> > > > > +       normal = false;
> > > > > +       vio_idx = -1;
> > > > > +       index = -1;
> > > > > +
> > > > > +       /* There are multiple DEVAPC_PD */
> > > > > +       for (slave_type = 0; slave_type < slave_type_num; slave_type++) {
> > > > > +               if (!check_type2_vio_status(slave_type, &vio_idx, &index))
> > > > > +                       if (!mtk_devapc_dump_vio_dbg(slave_type, &vio_idx,
> > > > > +                                                    &index))
> > > > > +                               continue;
> > > > > +
> > > > > +               /* Ensure that violation info are written before
> > > > > +                * further operations
> > > > > +                */
> > > > > +               smp_mb();
> > > > > +               normal = true;
> > > > > +
> > > > > +               mask_module_irq(slave_type, vio_idx, true);
> > > > > +
> > > > > +               if (clear_vio_status(slave_type, vio_idx))
> > > > > +                       pr_warn(PFX "%s, %s:0x%x, %s:0x%x\n",
> > > > > +                               "clear vio status failed",
> > > > > +                               "slave_type", slave_type,
> > > > > +                               "vio_index", vio_idx);
> > > > > +
> > > > > +               perm = get_permission(slave_type, index, vio_info->domain_id);
> > > > > +
> > > > > +               vio_master = mtk_devapc_ctx->soc->master_get
> > > > > +                       (vio_info->master_id,
> > > > > +                        vio_info->vio_addr,
> > > > > +                        slave_type,
> > > > > +                        vio_info->shift_sta_bit,
> > > > > +                        vio_info->domain_id);
> > > >
> > > > Call mt6873_bus_id_to_master() directly. For first patch, make things
> > > > as simple as possible.
> > >
> > > In devapc_violation_irq() function, we use common flow to handle each
> > > devapc violation on different platforms. The master_get() has different
> > > implementation on different platforms, that why it called indirectly.
> > >
> > > Once we have new platform, we only have to update devapc-mtxxxx.c
> > > instead of common handler flow.
> >
> > You just upstream one SoC now, so I have no information of 2nd SoC.
> > Without the 2nd SoC, how do we know what is common and what is SoC special?
> > So the first patch should not consider the things which does not exist yet.
> >
> > Regards,
> > Chun-Kuang.
> >
>
> It has lots of refactoring work need to do if you really want make it
> "simple". Could I explain more details and let you judge it is simple
> enough?

Making driver "simple" is very important, so it worth to spend effort
to make things simple. Everybody could modify this driver, so make
this driver simple and everybody would join this easily.

> For most MediaTek DEVAPC hw, the violation interrupt handling sequence
> is shown below.
>
> 1. Domain processor receives a interrupt issued by DEVAPC.
> 2. Software read the violation status and identify it.
> 3. Software read the debug information which are stored in hw register.
>         a. debug information includes master ID, domain ID, violation
> address, ...
> 4. Transfer debug information to human readable strings.
> 5. Extra handler to dispatch owner directly.

I don't know why need extra handler? What does this extra handler could do?
If indeed need it, separate extra handler part to an independent patch.

>
> What we really care is which master violates the rules, and which slave
> had been accessed unexpectedly.
>
> Here are platform specific information:
> 1. Slaves layout (platform devices)
> 2. hw register layout which are stored violation information
> 3. Master ID mapping table
> 4. Domain ID mapping table
>
> Hope these steps could help you understand what is common and what is
> SoC specific. If you want to see the 2nd SoC's driver, I can also send
> it for you to take a look.

Please upstream 2nd SoC's driver, so I could review common part and
SoC specific part.

Regards,
Chun-Kuang.

>
> Thanks,
> Neal
>
> > >
> > > >
> > > > > +
> > > > > +               if (!vio_master) {
> > > > > +                       pr_warn(PFX "master_get failed\n");
> > > > > +                       vio_master = "UNKNOWN_MASTER";
> > > > > +               }
> > > > > +
> > > > > +               pr_info(PFX "%s - %s:0x%x, %s:0x%x, %s:0x%x, %s:0x%x\n",
> > > > > +                       "Violation", "slave_type", slave_type,
> > > > > +                       "sys_index",
> > > > > +                       device_info[slave_type][index].sys_index,
> > > > > +                       "ctrl_index",
> > > > > +                       device_info[slave_type][index].ctrl_index,
> > > > > +                       "vio_index",
> > > > > +                       device_info[slave_type][index].vio_index);
> > > > > +
> > > > > +               pr_info(PFX "%s %s %s %s\n",
> > > > > +                       "Violation - master:", vio_master,
> > > > > +                       "access violation slave:",
> > > > > +                       device_info[slave_type][index].device);
> > > > > +
> > > > > +               devapc_vio_reason(perm);
> > > > > +
> > > > > +               devapc_extra_handler(slave_type, vio_master, vio_idx,
> > > > > +                                    vio_info->vio_addr);
> > > > > +
> > > > > +               mask_module_irq(slave_type, vio_idx, false);
> > > > > +       }
> > > > > +
> > > > > +       if (normal) {
> > > > > +               spin_unlock_irqrestore(&devapc_lock, flags);
> > > > > +               return IRQ_HANDLED;
> > > > > +       }
> > > > > +
> > > > > +       spin_unlock_irqrestore(&devapc_lock, flags);
> > > > > +       return IRQ_HANDLED;
> > > > > +}
> > > > > +
> > >
> > > [snip]
> > >
> > >
>

  reply	other threads:[~2020-06-12 15:28 UTC|newest]

Thread overview: 21+ 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 ` [PATCH 1/2] dt-bindings: devapc: add bindings for devapc-mt6873 Neal Liu
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 16:01   ` Chun-Kuang Hu
2020-06-11  9:26     ` Neal Liu
2020-06-11 11:01       ` Chun-Kuang Hu
2020-06-12  3:04         ` Neal Liu
2020-06-12 15:27           ` Chun-Kuang Hu [this message]
2020-06-15  2:12             ` Neal Liu
2020-06-12 23:20   ` Chun-Kuang Hu
2020-06-16  6:45     ` Neal Liu
2020-06-14  3:26   ` Chun-Kuang Hu
2020-06-15  2:43     ` Neal Liu
2020-06-15 14:14       ` Chun-Kuang Hu
2020-06-15 14:17         ` Chun-Kuang Hu
2020-06-16  6:09           ` Neal Liu
2020-06-15 15:51   ` Chun-Kuang Hu
2020-06-16  6:19     ` Neal Liu
2020-06-09 17:32 ` Add MediaTek MT6873 devapc driver Rob Herring
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=CAAOTY__zXZvv1gcKgxnbpv2RjDLyuQ1NEz8Nr+dtn4GKE1cvMA@mail.gmail.com \
    --to=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=neal.liu@mediatek.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 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).