From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.bootlin.com ([62.4.15.54]:44987 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbeECIBQ (ORCPT ); Thu, 3 May 2018 04:01:16 -0400 Date: Thu, 3 May 2018 10:01:14 +0200 From: Miquel Raynal To: Boris Brezillon Cc: Chris Packham , Richard Weinberger , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" , Marek Vasut , "linux-mtd@lists.infradead.org" , Brian Norris , David Woodhouse Subject: Re: [PATCH] mtd: rawnand: marvell: pass ms delay to wait_op Message-ID: <20180503100114.16d573dc@xps13> In-Reply-To: <20180503090348.0c10b00f@bbrezillon> References: <20180503022128.10702-1-chris.packham@alliedtelesis.co.nz> <20180503090348.0c10b00f@bbrezillon> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: stable-owner@vger.kernel.org List-ID: Hi Boris, Chris, > > > diff --git a/drivers/mtd/nand/raw/marvell_nand.c b/drivers/mtd/nand/raw/marvell_nand.c > > > index 1d779a35ac8e..e4b964fd40d8 100644 > > > --- a/drivers/mtd/nand/raw/marvell_nand.c > > > +++ b/drivers/mtd/nand/raw/marvell_nand.c > > > @@ -1074,7 +1074,7 @@ static int marvell_nfc_hw_ecc_hmg_do_write_page(struct nand_chip *chip, > > > return ret; > > > > > > ret = marvell_nfc_wait_op(chip, > > > - chip->data_interface.timings.sdr.tPROG_max); > > > + PSEC_TO_MSEC(chip->data_interface.timings.sdr.tPROG_max)); > > > return ret; > > > } > > > > > > @@ -1494,7 +1494,7 @@ static int marvell_nfc_hw_ecc_bch_write_page(struct mtd_info *mtd, > > > } > > > > > > ret = marvell_nfc_wait_op(chip, > > > - chip->data_interface.timings.sdr.tPROG_max); > > > + PSEC_TO_MSEC(chip->data_interface.timings.sdr.tPROG_max)); > > > [...] > > The old pxa3xx driver had hard coded 200ms delays. These delays now work > > out to 1ms which seems every bit as wrong as 600000000ms. When the 'keep-config' property is populated, the ->setup_data_interface() hook of the driver is not shown to the core, which leads to not "updating" the timings like tPROG_max. While it worked with the old driver that hardcoded this delay, this might not work anymore with the current driver because it expects timings.sdr.tPROG_max to be != 0 (and PSEC_TO_MSEC(0) also returns 0). This is probably something to fix. Regards, Miquèl -- Miquel Raynal, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com