Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp6962644yba; Thu, 2 May 2019 01:26:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqzxoUtOHzuaHRxCfd4yPIaSpF5cub/malWNi+QdGZ8loeCF/OJ0Kh0+X3aaUD4urC16Kd8x X-Received: by 2002:a17:902:bc81:: with SMTP id bb1mr2435725plb.330.1556785597951; Thu, 02 May 2019 01:26:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556785597; cv=none; d=google.com; s=arc-20160816; b=y5CmWznfP3y0Baccqyz2bznEZikqQc0LU9wnnwKwFAbq2UPEtg0EeBgmAli66TYTWA MjBYxWbO7Ec5cTqUvCPOLohTltpoytAACP0PnOiF/muvYaMm4ACB1udnaqzbQtMGY5k+ GnB1zsPjU/hjRvp7ebuagyfLjs67DhzJhkk9qub2V7jtMKQxShMAG7vq3pYTG8HWFvzA CsBS8hYc+4/gSH3wnun6oH695YEpsRjMQqfs+fvfLJdycFTLlJfMCOkOCskkyMCZTCnj K8vwSMqUaWRJStPrUfZgY51gfIhszAmfWR1oIXCfrL98VpJ9XT8wRGbOvud7wfo7JKR2 YTWw== 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:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=UWH/Ola9N1SLnq21vUqFWLOSnMOmPqGQKh4pwbphAX8=; b=tYcIlzxfOBz3E66jpZyVoJ8HHVfpEKRJ5RHnYiuZeRp0BVnPHPgY8OxqMSQFtzngVX cgYog6LwKZ7iGFR+V/gNHYokleJCLu7dmqOnClEgWZv3o/YVjuf8Efsbnbdj/Zx2a92b wkc5DcglQCCVM891GtsGDBPgzl0x1nDJtqvR1pNF204E3HyOb1AQgUNRO3sVt95AhsTU Tee48ueN8MYlv8meBY1yNVSbqkrD7PdjG0B+1zO4x0VJS/49f0j7myy+oNjfaHMXt5hf vQm7jmB88JZAqSIuNNQKX7Qdc0bqdI6rIYmpbg5HDVIveEJQgQ0mE/qDGq0ZKDNUPcjn HiXA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w22si42405469pgj.174.2019.05.02.01.26.22; Thu, 02 May 2019 01:26: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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726400AbfEBIZL convert rfc822-to-8bit (ORCPT + 99 others); Thu, 2 May 2019 04:25:11 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:53479 "EHLO relay11.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725944AbfEBIZK (ORCPT ); Thu, 2 May 2019 04:25:10 -0400 Received: from xps13 (aaubervilliers-681-1-29-145.w90-88.abo.wanadoo.fr [90.88.149.145]) (Authenticated sender: miquel.raynal@bootlin.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 3B27810001D; Thu, 2 May 2019 08:25:05 +0000 (UTC) Date: Thu, 2 May 2019 10:25:04 +0200 From: Miquel Raynal To: Kamal Dasu Cc: linux-mtd@lists.infradead.org, bcm-kernel-feedback-list@broadcom.com, linux-kernel@vger.kernel.org, Brian Norris , Boris Brezillon , Richard Weinberger , David Woodhouse , Marek Vasut Subject: Re: [PATCH] mtd: nand: raw: brcmnand: When oops in progress use pio and interrupt polling Message-ID: <20190502102504.32b45247@xps13> In-Reply-To: <1556733121-20133-1-git-send-email-kdasu.kdev@gmail.com> References: <1556733121-20133-1-git-send-email-kdasu.kdev@gmail.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 completion s/nand/NAND/ > 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." > This is needed in > cases where the panic does not happen on cpu0 and there is only one online > 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? > > 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/nand/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_controller *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 = 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 = 0; > + > +#ifdef CONFIG_MTD_OOPS > + if (oops_in_progress && smp_processor_id()) { > + int cpu = 0; > + > + for_each_online_cpu(cpu) > + ++i; > + } > +#endif > + return i == 1 ? true : false; I suppose return (i == 1); is enough > +} > + > +static bool brcmstb_nand_wait_for_completion(struct nand_chip *chip) > +{ > + struct brcmnand_host *host = nand_get_controller_data(chip); > + struct brcmnand_controller *ctrl = host->ctrl; > + bool err = false; > + int sts; > + > + if (is_mtd_oops_in_progress()) { > + /* Switch to interrupt polling and PIO mode */ > + disable_flash_dma_xfer(ctrl); > + sts = bcmnand_ctrl_poll_status(ctrl, NAND_CTRL_RDY | > + NAND_STATUS_READY, > + NAND_CTRL_RDY | > + NAND_STATUS_READY, 0); > + err = (sts < 0) ? true : false; > + } else { > + unsigned long timeo = msecs_to_jiffies( > + NAND_POLL_STATUS_TIMEOUT_MS); > + /* wait for completion interrupt */ > + sts = wait_for_completion_timeout(&ctrl->done, timeo); > + err = (sts <= 0) ? true : false; > + } > + > + return err; > +} > + > static int brcmnand_waitfunc(struct nand_chip *chip) > { > struct brcmnand_host *host = nand_get_controller_data(chip); > struct brcmnand_controller *ctrl = host->ctrl; > - unsigned long timeo = msecs_to_jiffies(100); > + bool err = 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) <= 0) { What about the wait_for_completion_timeout() call in brcmnand_write()? > + if (ctrl->cmd_pending) > + err = brcmstb_nand_wait_for_completion(chip); > + > + if (err) { > u32 cmd = brcmnand_read_reg(ctrl, BRCMNAND_CMD_START) > >> brcmnand_cmd_shift(ctrl); > Thanks, Miquèl