Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp7272657yba; Thu, 2 May 2019 07:13:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqxpgz749hoMdDlBo5MH2mGUwpF8jZOjo+uMr7O9md6fcJ2rfH+3xhfhKSs3i0ZVxxujk5qU X-Received: by 2002:a62:480d:: with SMTP id v13mr4499046pfa.125.1556806417043; Thu, 02 May 2019 07:13:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556806417; cv=none; d=google.com; s=arc-20160816; b=jGyoOQwQMqiXjnOJ/+WT1pxQaHds5ZGub9Svt2u5PkwySERH+Pj3WmqH4rCp2cX6Dp 1WGroo3jYEaQNmk3J/I0g6++3UqXO/3USkP+nc+Yk4MM5sexGZjnYBBoJfVoD4k/6p43 UdTF3VcJ0gMGFap6q9wHcYzH1u58wxyl/PJzfQ9TS1Q25NnrP4PxVBl5dkkoKVRPP18B Z3Nj2nWgum9IBE/nTjycIl3mRdkhYjqvhwEEW9g5XaSK4bBAhfpsFOcDetGoMzON64Sx Cm0WLdS2sW5loQ/StUpyfQe9TgGDlhqXrE/XW4aIyeNzkwIhZz6FepVG5yYvxoqdPMWE GwYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=CzTxP9dt0cEMXB8ZLT3bRjyPydmwtmQUnqm59Ipu0B4=; b=EvSy87dIdboF/bXA/q9FBE49176/Jox+rTBTO06mvTmhJzFm4svHLPf010Gx1+Jg2M LgvHWPVs2RJj0NetXzwxpOLk62Zpx6s3AAu8SQ/fPyHhEm1LDTHv1GdoNJreRg1qFVTG c4IM8/NCcIEo12799VV3RscwIvRgtwX04rI2As8wQR+QQByXNupe9wWqrc/cEiiXk0Zq 3HqG4HHGDVIysfp4+uE7eKgvoylizLAXAGq2MCBKhROtvv25LJ/zg159aLWu8oFiNqxW R4+uNCzlslmN7VcwxgXTByRqWdMGDZBCClN6QB5f/ptDif5Wi/MUH7IfCzFwL0jt+q/Q rwCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="nA/Hb8t6"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w6si41474681pgr.71.2019.05.02.07.13.20; Thu, 02 May 2019 07:13:37 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b="nA/Hb8t6"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726450AbfEBOKL (ORCPT + 99 others); Thu, 2 May 2019 10:10:11 -0400 Received: from mail-it1-f194.google.com ([209.85.166.194]:39203 "EHLO mail-it1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726197AbfEBOKL (ORCPT ); Thu, 2 May 2019 10:10:11 -0400 Received: by mail-it1-f194.google.com with SMTP id t200so3598169itf.4 for ; Thu, 02 May 2019 07:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CzTxP9dt0cEMXB8ZLT3bRjyPydmwtmQUnqm59Ipu0B4=; b=nA/Hb8t6zTovVxuEPyklmYdY8j53hus6O8CQ38Q+5dhleYhDtgeBymV3sa5M28ICVj fmDBLtsYtXmcjdf15PVFxtxzM34IkSVqF6HIKVOprxxBedZVp27TlplVqtHXU89wTogK rcnj0busIRJz6arYPdZEmsIOGqsZkGz0RGaXdZaluJ7r06VdYT8J0+VZp3aWX9FrAfPo wQ3aEVOIwN7t8aE2iOiScg0Jk7a3U2TNAKcUWVFJf49P1Bd40J6pqnngAqr3UUTGFDu1 qwdRsSADf2nQauOacVpLiKe7n/2kL0lFSsmwptI0Ltwa0aYQBOJtGhTsl7iLgzmkl/PR Cayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CzTxP9dt0cEMXB8ZLT3bRjyPydmwtmQUnqm59Ipu0B4=; b=fDgnnJH28AlORI3jA21QBi03xLHnSk3M/YMbWiF/bcq4ya1sN9576aB5AfdW3A887l G00EhUhZAWC+e+95F+Q9gerh9OR5ErU06l5D0C8CeEtwHehYkugB+eSfLqJR+AjZOhb3 xxmMkzVb3DT/xXsy22Wtig7fST2MAIkxM5dhMoP4hV/i90HWQD3l1RcX5Lv7vKMsEifI HhE3RmXBBVxZke3YxTH6DQYG6NZ1/jGSz1yanD7D8BBDXdIdu3+qdzJMBsEtDPAAwxZp vOhtc6vj199F0GW9Nz4hEJ74V4VMRdQ9HUgLv1MM6oUSibodquGirq+DMVskU/X+OIyR Sjjg== X-Gm-Message-State: APjAAAVSSMQbRdudFcwcXokdDaDj9pyjg+VRQMUad+xsabFe+aXHYXHQ c9SXSZvlKQVJlnUqQP3TZLQi5+9LbPyaBfj+kIc= X-Received: by 2002:a24:1104:: with SMTP id 4mr2237306itf.10.1556806210165; Thu, 02 May 2019 07:10:10 -0700 (PDT) MIME-Version: 1.0 References: <1556733121-20133-1-git-send-email-kdasu.kdev@gmail.com> <20190502102504.32b45247@xps13> In-Reply-To: <20190502102504.32b45247@xps13> From: Kamal Dasu Date: Thu, 2 May 2019 10:09:59 -0400 Message-ID: Subject: Re: [PATCH] mtd: nand: raw: brcmnand: When oops in progress use pio and interrupt polling To: Miquel Raynal Cc: MTD Maling List , bcm-kernel-feedback-list@broadcom.com, Linux Kernel Mailing List , Brian Norris , Boris Brezillon , Richard Weinberger , David Woodhouse , Marek Vasut Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 2, 2019 at 4:25 AM Miquel Raynal wr= ote: > > Hi Kamal, > > Kamal Dasu wrote on Wed, 1 May 2019 13:46:15 > -0400: > > > If mtd_oops is in progress switch to polling for nand command completio= n > > s/nand/NAND/ Will change this. > > > interrupts and use PIO mode wihtout DMA so that the mtd_oops buffer can > > be completely written in the assinged nand partition. > > What about: > > "If mtd_oops is in progress, switch to polling during NAND command > completion instead of relying on DMA/interrupts so that the mtd_oops > buffer can be completely written in the assigned NAND partition." > Will make this change as well > > This is needed in > > cases where the panic does not happen on cpu0 and there is only one onl= ine > > CPU and the panic is not on cpu0. > > "This is needed in case the panic does not happen on CPU0 and there is > only one online CPU." > > I am not sure to understand the problem or how this can happen (and > be a problem). Have you met such issue already or is this purely > speculative? We have seen this issue and tested it on multi core SoCs. > > > > > Signed-off-by: Kamal Dasu > > --- > > drivers/mtd/nand/raw/brcmnand/brcmnand.c | 55 ++++++++++++++++++++++++= ++++++-- > > 1 file changed, 52 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c b/drivers/mtd/nan= d/raw/brcmnand/brcmnand.c > > index 482c6f0..cfbe51a 100644 > > --- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > +++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c > > @@ -823,6 +823,12 @@ static inline bool has_flash_dma(struct brcmnand_c= ontroller *ctrl) > > return ctrl->flash_dma_base; > > } > > > > +static inline void disable_flash_dma_xfer(struct brcmnand_controller *= ctrl) > > +{ > > + if (has_flash_dma(ctrl)) > > + ctrl->flash_dma_base =3D 0; > > +} > > + > > static inline bool flash_dma_buf_ok(const void *buf) > > { > > return buf && !is_vmalloc_addr(buf) && > > @@ -1237,15 +1243,58 @@ static void brcmnand_cmd_ctrl(struct nand_chip = *chip, int dat, > > /* intentionally left blank */ > > } > > > > +static bool is_mtd_oops_in_progress(void) > > +{ > > + int i =3D 0; > > + > > +#ifdef CONFIG_MTD_OOPS > > + if (oops_in_progress && smp_processor_id()) { > > + int cpu =3D 0; > > + > > + for_each_online_cpu(cpu) > > + ++i; > > + } > > +#endif > > + return i =3D=3D 1 ? true : false; > > I suppose return (i =3D=3D 1); is enough > Ok will make the change. > > +} > > + > > +static bool brcmstb_nand_wait_for_completion(struct nand_chip *chip) > > +{ > > + struct brcmnand_host *host =3D nand_get_controller_data(chip); > > + struct brcmnand_controller *ctrl =3D host->ctrl; > > + bool err =3D false; > > + int sts; > > + > > + if (is_mtd_oops_in_progress()) { > > + /* Switch to interrupt polling and PIO mode */ > > + disable_flash_dma_xfer(ctrl); > > + sts =3D bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY | > > + NAND_STATUS_READY, > > + NAND_CTRL_RDY | > > + NAND_STATUS_READY, 0); > > + err =3D (sts < 0) ? true : false; > > + } else { > > + unsigned long timeo =3D msecs_to_jiffies( > > + NAND_POLL_STATUS_TIMEOUT_= MS); > > + /* wait for completion interrupt */ > > + sts =3D wait_for_completion_timeout(&ctrl->done, timeo); > > + err =3D (sts <=3D 0) ? true : false; > > + } > > + > > + return err; > > +} > > + > > static int brcmnand_waitfunc(struct nand_chip *chip) > > { > > struct brcmnand_host *host =3D nand_get_controller_data(chip); > > struct brcmnand_controller *ctrl =3D host->ctrl; > > - unsigned long timeo =3D msecs_to_jiffies(100); > > + bool err =3D false; > > > > dev_dbg(ctrl->dev, "wait on native cmd %d\n", ctrl->cmd_pending); > > - if (ctrl->cmd_pending && > > - wait_for_completion_timeout(&ctrl->done, timeo) <= =3D 0) { > > What about the wait_for_completion_timeout() call in brcmnand_write()? > brcmnand_write() too calls brcmnand_waitfunc(), will poll if it needs to for completion. > > + if (ctrl->cmd_pending) > > + err =3D brcmstb_nand_wait_for_completion(chip); > > + > > + if (err) { > > u32 cmd =3D brcmnand_read_reg(ctrl, BRCMNAND_CMD_START) > > >> brcmnand_cmd_shift(ctrl); > > > > > Thanks, > Miqu=C3=A8l Thanks Kamal