Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver
To:     Neal Liu <neal.liu@mediatek.com>
Cc:     Rob Herring <robh+dt@kernel.org>,
        Chun-Kuang Hu <chunkuang.hu@kernel.org>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-mediatek@lists.infradead.org" 
        <linux-mediatek@lists.infradead.org>,
        lkml <linux-kernel@vger.kernel.org>,
        wsd_upstream <wsd_upstream@mediatek.com>
References: <1598497593-15781-1-git-send-email-neal.liu@mediatek.com>
 <1598497593-15781-3-git-send-email-neal.liu@mediatek.com>
 <c41ec664-73a0-3c63-a31c-48c89028dfac@gmail.com>
 <1602124514.28301.17.camel@mtkswgap22> <1602728017.11536.5.camel@mtkswgap22>
From:   Matthias Brugger <matthias.bgg@gmail.com>
Message-ID: <bf202a0f-49e3-c618-5d74-934fe739dd18@gmail.com>
Date:   Thu, 15 Oct 2020 11:13:47 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <1602728017.11536.5.camel@mtkswgap22>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 15/10/2020 04:13, Neal Liu wrote:
> On Thu, 2020-10-08 at 10:35 +0800, Neal Liu wrote:
>> On Wed, 2020-10-07 at 12:44 +0200, Matthias Brugger wrote:
>>>
>>> On 27/08/2020 05:06, Neal Liu wrote:
> [...]
> 
>>>> +static int devapc_sync_vio_dbg(struct mtk_devapc_context *ctx)
>>>> +{
>>>> +	void __iomem *pd_vio_shift_sta_reg;
>>>> +	void __iomem *pd_vio_shift_sel_reg;
>>>> +	void __iomem *pd_vio_shift_con_reg;
>>>> +	int min_shift_group;
>>>> +	int ret;
>>>> +	u32 val;
>>>> +
>>>> +	pd_vio_shift_sta_reg = ctx->infra_base +
>>>> +			       ctx->data->vio_shift_sta_offset;
>>>> +	pd_vio_shift_sel_reg = ctx->infra_base +
>>>> +			       ctx->data->vio_shift_sel_offset;
>>>> +	pd_vio_shift_con_reg = ctx->infra_base +
>>>> +			       ctx->data->vio_shift_con_offset;
>>>> +
>>>> +	/* Find the minimum shift group which has violation */
>>>> +	val = readl(pd_vio_shift_sta_reg);
>>>> +	if (!val)
>>>> +		return false;
>>>
>>> So bit 0 of selection register (pd_vio_shift_sel_reg) does not represent a
>>> violation group?
>>> I don't know how the HW works, but is seems odd to me. In case that's bit 0
>>> actually doesn't represent anything: how can an interrupt be triggered without
>>> any debug information present (means val == 0)?
>>
>> This check implies HW status has something wrong. It cannot get any
>> debug information for this case.
>> It won't happen in normal scenario. Should we remove this check?
>>
> 
> Sorry, I missed the most common part. Is function is in the while loop:
> while (devapc_sync_vio_dbg(ctx))
> ...
> 
> We keep find the minimum bit in pd_vio_shift_sta_reg to get the
> violation information, (pd_vio_shift_sta_reg might raise multiple bits)
> until all raised bit (shift group) has been handled.
> So I don't think it's necessary to add WARN message in this case.
> Thanks
> 

Correct we would get a warning every time once we have read and cleared all 
violations, but we are only concerned about the IRQ triggered with no violation 
present. But we can skip that check for now, if we see that there could be a HW 
error we can think about it in the future.

Regards,
Matthias