From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68A6822616C for ; Thu, 19 Dec 2024 16:12:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734624747; cv=none; b=douBNGYPbn7gbLgPNlN2w/vkVnlDcNNcvNnJC/huKSGkRrXVgPmXZ/xYoNbLzpYMiX3hNLwrgoxBnaeFJ4xjaix2o4tM2Ft3rNLsVEtfIb7+Ckj6hK+ylufyuMkby3893h3+Bs7GYfBAJE0TsrxJpAFpvl1/Cac06DjmU5dDcxI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734624747; c=relaxed/simple; bh=h7unGDc1KGApKq6m38t0cz5hbZP/MiWsKQ5zEV6jG6A=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=uuUF1Inx+HdMbWr5LrV+F3JakA8BeVlq1dFlK2Wq5oKV0ekZQl+fl7fxUGogeIdNpNX7BrdfnIJyoaHAEa1hJyFIlQZLHT2w2tteMGfy3rT8shg3HXNTYJrQD3h2F/iCgl09HO4uPNt5hwkL7SML8+uuujbxYR13mHBaDbed7mw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=pvh6wFEa; arc=none smtp.client-ip=217.70.183.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="pvh6wFEa" Received: by mail.gandi.net (Postfix) with ESMTPSA id 9870C1BF20D; Thu, 19 Dec 2024 16:12:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1734624737; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KvRSHK5bNFiDE6BSVtHafrHHc5HkI14nnlQQyrtKneI=; b=pvh6wFEaKGR/RBELeUbwxgeFFppP1J87eJfT1dkCZyocAko/BL8AVKL8Dv2tp0qZ7dCHdn ImyVN2Rw5Cf2+wieHCCRZ+IJ8C6DxaNwBrUWI5cdACDOJfzj5oPvdZecBRbWiPXzFOpkJP hSejNiSYbNr3VzHRok6Nideq3gbQR85inI0N1S8R5RTtWYh20YGfLDrdMKjFFK0Hk76zg6 zNJy38iX4O7EZ6Yc6XbAF6XSPwujVbwhxxR5bVEbwBR9OWJ5EDuS2aA4+4ptZ/uvHTe+i3 i0feZiJDfmmjE7kR3QgFewae6H9YqSXu9PdgORe5aTzVyrsk2em4EXEUnXNZxw== From: Miquel Raynal To: Bastien Curutchet Cc: Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, Thomas Petazzoni , Herve Codina , Christopher Cordahi Subject: Re: [PATCH v2] mtd: rawnand: davinci: Reduce polling interval in NAND_OP_WAITRDY_INSTR In-Reply-To: <20241219-patch-nand-poll-v2-1-cc80a1ee4e0f@bootlin.com> (Bastien Curutchet's message of "Thu, 19 Dec 2024 15:58:10 +0100") References: <20241219-patch-nand-poll-v2-1-cc80a1ee4e0f@bootlin.com> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Thu, 19 Dec 2024 17:12:16 +0100 Message-ID: <87a5crabz3.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hello Bastien, On 19/12/2024 at 15:58:10 +01, Bastien Curutchet wrote: > For each NAND_OP_WAITRDY_INSTR operation, the NANDFSR register is > polled only once every 100 us to check for the EMA_WAIT pin. This > isn't frequent enough and causes delays in NAND accesses. > > Set the polling interval to 0s. It increases the page read speed > reported by flash_speed by ~40% (~30% on page writes). ... > case NAND_OP_WAITRDY_INSTR: > timeout_us =3D instr->ctx.waitrdy.timeout_ms * 1000; > ret =3D readl_relaxed_poll_timeout(info->base + NANDFSR_OFFSET, > - status, status & BIT(0), 100, > + status, status & BIT(0), 0, This kind of optimization is very tempting but has an impact on the system. I am fine reducing this polling delay, but maybe not down to 0 which means you busy wait the entire time. For reads it might be fine because tR is rather short, but for writes it is a bit more impacting and for erases it will have a true system wide impact. So what you see in the benchmark is specific to the NAND driver performances, but fails to give you the system-wide big picture which I think is worth keeping in mind. As this value will be NAND specific we cannot fine tune it too much, but I would suggest to try finding a lower value without reaching 0. Like 5 or 10 us maybe. Thanks, Miqu=C3=A8l