Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 8 Apr 2020 08:40:21 +0200
From:   Robert Richter <rrichter@marvell.com>
To:     Sherry Sun <sherry.sun@nxp.com>
CC:     "bp@alien8.de" <bp@alien8.de>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "tony.luck@intel.com" <tony.luck@intel.com>,
        "james.morse@arm.com" <james.morse@arm.com>,
        "michal.simek@xilinx.com" <michal.simek@xilinx.com>,
        "manish.narani@xilinx.com" <manish.narani@xilinx.com>,
        "linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>, Frank Li <frank.li@nxp.com>
Subject: Re: [patch v3 3/4] EDAC: synopsys: Add edac driver support for
 i.MX8MP
Message-ID: <20200408064020.fjg55j7vvcvsqxgb@rric.localdomain>
References: <1585790433-31465-1-git-send-email-sherry.sun@nxp.com>
 <1585790433-31465-4-git-send-email-sherry.sun@nxp.com>
 <20200402072200.o6c6u3uim6jwopo6@rric.localdomain>
 <VI1PR04MB4960985DD2A4F0CA68063D9592C60@VI1PR04MB4960.eurprd04.prod.outlook.com>
 <20200402111709.qr7zpo5o5vrwh5kb@rric.localdomain>
 <VI1PR04MB4960DF2EF1961DCF74655BF592C60@VI1PR04MB4960.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <VI1PR04MB4960DF2EF1961DCF74655BF592C60@VI1PR04MB4960.eurprd04.prod.outlook.com>
User-Agent: NeoMutt/20170113 (1.7.2)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from rric.localdomain (31.208.96.227) by HE1PR05CA0258.eurprd05.prod.outlook.com (2603:10a6:3:fb::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20 via Frontend Transport; Wed, 8 Apr 2020 06:40:29 +0000
X-Originating-IP: [31.208.96.227]
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 91430619-17dd-4069-1fb2-08d7db87bc37
X-MS-TrafficTypeDiagnostic: BYAPR18MB2437:
X-Microsoft-Antispam-PRVS: <BYAPR18MB2437429A6C12F50D196CA24AD9C00@BYAPR18MB2437.namprd18.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8882;
X-Forefront-PRVS: 0367A50BB1
X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:BYAPR18MB2661.namprd18.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:(10009020)(4636009)(396003)(376002)(346002)(366004)(136003)(39860400002)(956004)(6506007)(16526019)(55016002)(478600001)(186003)(1076003)(6666004)(81166007)(9686003)(6916009)(66476007)(4326008)(5660300002)(66556008)(7416002)(81156014)(8676002)(53546011)(66946007)(54906003)(52116002)(2906002)(26005)(316002)(8936002)(86362001)(7696005);DIR:OUT;SFP:1101;
Received-SPF: None (protection.outlook.com: marvell.com does not designate
 permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: t9Cc6VhFuFrLmt4ZYBz1JZsjdGW/yAVLvweWJCPRw3RIqF9YNOksWRONyJL149VDEtr7xwOPsIa6bAt2hBGicPnElFxBV/OXtb7AIBU1JlSpBABOxDJ67AfisilMP8BagdUofxc5WLQr/DX7yqe0h7hXgvGM+gjZmNbajWeDzDQVqX8FMNG5lrJ0M374VZlkpsjHYecIDHSZTooRNg+WGom5z1kjKOI8xlG89BqzQuPMuTJDSxrNDVh/XSpB8oGsCIvW/EenTVSrS2fsLFfySIkwxJFdlwl3YBHdHKLAude6x+xsz7hL4qIg6gYHghCtzi1VrR6I2THfzo7zRoSjsacX7PmAK5GeNuhAkCKwgP2wYokiIxIBENnJLdMkEQd50Jo0PQP4wQqi8YnGjvRzx4NzeiBdwLUoM7rvhV0+vGRjDWHifb/AVtMO4Cbmc+14
X-MS-Exchange-AntiSpam-MessageData: l+JGBovwtLVoOwRftUPfLBN8P3KWL3H9gJ69MiofOHe73HzRjLqzSbbWSWQOXlw84ZJbTlwYtIarzPHtdIwxrsWKIqizlifvDYfmQ+hoXC+xt3suwYUpp+9Z7eqQjhN4nSBPxjHzTkUHi0MuiP95Bg==
X-MS-Exchange-CrossTenant-Network-Message-Id: 91430619-17dd-4069-1fb2-08d7db87bc37
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 06:40:32.5968
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 70e1fb47-1155-421d-87fc-2e58f638b6e0
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: y6pWsoaEvBXzQCr3GtdHB3GMmLA2IdU/5VOL3u+ZFnDxKP9A7RE+y0CUkxaeilDpoGW50WCpZSgIm3pqb/qjRQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2437
X-OriginatorOrg: marvell.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.676
 definitions=2020-04-07_10:2020-04-07,2020-04-07 signatures=0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 02.04.20 13:09:57, Sherry Sun wrote:
> > From: Robert Richter <rrichter@marvell.com>
> > On 02.04.20 09:06:27, Sherry Sun wrote:
> > > > From: Robert Richter <rrichter@marvell.com> On 02.04.20 09:20:32,

> > > > > +/* Interrupt Handler for ECC interrupts on imx8mp platform. */
> > > > > +static irqreturn_t intr_handler_imx8mp(int irq, void *dev_id) {
> > > > > +	const struct synps_platform_data *p_data;
> > > > > +	struct mem_ctl_info *mci = dev_id;
> > > > > +	struct synps_edac_priv *priv;
> > > > > +	int status, regval;
> > > > > +
> > > > > +	priv = mci->pvt_info;
> > > > > +	p_data = priv->p_data;
> > > > > +
> > > > > +	regval = readl(priv->baseaddr + ECC_STAT_OFST);
> > > > > +	if (!(regval & ECC_INTR_MASK))
> > > > > +		return IRQ_NONE;
> > > > > +
> > > > > +	status = p_data->get_error_info(priv);
> > > > > +	if (status)
> > > > > +		return IRQ_NONE;
> > > > > +
> > > > > +	priv->ce_cnt += priv->stat.ce_cnt;
> > > > > +	priv->ue_cnt += priv->stat.ue_cnt;
> > > > > +	handle_error(mci, &priv->stat);
> > > > > +
> > > > > +	edac_dbg(3, "Total error count CE %d UE %d\n",
> > > > > +		 priv->ce_cnt, priv->ue_cnt);
 > > > > > +	enable_intr_imx8mp(priv);
> > > >
> > > > Why do you enable interrupts here?
> > >
> > > Because zynqmp_get_error_info() wrote 0 to ECC_CLR_OFST, so here have
> > to re-enable the interrupts.
> > 
> > This does not seem to be the right place for it.
> > 
> > > As said in the commit, the main difference between ZynqMP and i.MX8MP
> > ddr controller is the interrupt registers.
> > > ZynqMP use DDR QOS Interrupt registers,  but i.MX8MP use ECC_CLR_OFST
> > Register(bit8 and bit9) to enable/disable the ce/ue interrupts.
> > >
> > > In zynqmp_get_error_info(), Zynqmp wrote 0 to ECC_CLR_OFST register to
> > clear CE/UE error flags and counts, it has no effect on Zynqmp interrupts.
> > > But for i.MX8MP, wirte 0 to ECC_CLR_OFST will disable i.MX8MP CE/UE
> > interrupt, so need re-enable the interrupts.
> > 
> > All this shows one more time there should be separate handlers. You should
> > get rid most callbacks in struct synps_platform_data and instead have
> > separate probe functions for both flavors that share common code.
> 
> Do you mean that I should create specific callbacks in struct synps_platform_data for i.MX8MP instead reuse the ZynqMP functions?
> But except this operation of write 0 to ECC_CLR_OFST in zynqmp_get_error_info(), 
> the other callbacks in struct synps_platform_data are all the same between ZynqMP and i.MX8MP.

Most callbacks in struct synps_platform_data will become obsolete if
there are either device tailored functions or if the width parameter
would be stored in private data and used by a common function.

-Robert