Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752536AbbDAPLB (ORCPT ); Wed, 1 Apr 2015 11:11:01 -0400 Received: from xes-mad.com ([216.165.139.218]:33249 "EHLO xes-mad.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751178AbbDAPLA (ORCPT ); Wed, 1 Apr 2015 11:11:00 -0400 Date: Wed, 1 Apr 2015 10:08:24 -0500 (CDT) From: Aaron Sierra To: Nicholas Mc Guire Cc: Nicholas Mc Guire , David Woodhouse , Brian Norris , Joe Schultz , Wolfram Sang , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Message-ID: <699783288.22321.1427900904422.JavaMail.zimbra@xes-inc.com> In-Reply-To: <20150401142444.GA12125@opentech.at> References: <1426245828-15640-1-git-send-email-hofrat@osadl.org> <1162655988.11370.1427896685060.JavaMail.zimbra@xes-inc.com> <20150401142444.GA12125@opentech.at> Subject: Re: [PATCH] mtd: fsl_ifc_nand: use msecs_to_jiffies for time conversion MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.52.16.65] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF35 (Linux)/8.0.6_GA_5922) Thread-Topic: fsl_ifc_nand: use msecs_to_jiffies for time conversion Thread-Index: WznAkDv8pIGHuellV46FI7aMIhypSA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2911 Lines: 75 ----- Original Message ----- > From: "Nicholas Mc Guire" > Sent: Wednesday, April 1, 2015 9:24:44 AM > > On Wed, 01 Apr 2015, Aaron Sierra wrote: > > > ----- Original Message ----- > > > From: "Nicholas Mc Guire" > > > Sent: Friday, March 13, 2015 6:23:47 AM > > > > > > This is only an API consolidation and should make things more readable > > > it replaces var * HZ / 1000 by msecs_to_jiffies(var) which helps > > > readability > > > and also handles all corner-cases properly. > > > > > > Signed-off-by: Nicholas Mc Guire > > > --- > > > > > > Patch was compile tested with corenet64_smp_defconfig > > > (implies CONFIG_MTD_NAND_FSL_IFC=y) > > > > > > Patch is against 4.0-rc3 (localversion-next is -next-20150313 > > > > > > drivers/mtd/nand/fsl_ifc_nand.c | 4 ++-- > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/mtd/nand/fsl_ifc_nand.c > > > b/drivers/mtd/nand/fsl_ifc_nand.c > > > index 4c05f4f..51394e5 100644 > > > --- a/drivers/mtd/nand/fsl_ifc_nand.c > > > +++ b/drivers/mtd/nand/fsl_ifc_nand.c > > > @@ -317,7 +317,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) > > > > > > /* wait for command complete flag or timeout */ > > > wait_event_timeout(ctrl->nand_wait, ctrl->nand_stat, > > > - IFC_TIMEOUT_MSECS * HZ/1000); > > > + msecs_to_jiffies(IFC_TIMEOUT_MSECS)); > > > > Nicholas, > > Your patch makes me think that this timeout value should be calculated > > once during initialization and stored in a new member of > > struct fsl_ifc_mtd. That would improve readability AND have some > > positive impact on performance. > > > > is it not a bit wasteful to put it into struct fsl_ifc_mtd > which is used quite often in here ? Storing the timeout in the private structure would use 4 or 8 bytes, but the structure is passed around as pointer reference, so there is no added overhead there. > #define IFC_TIMEOUT msecs_to_jiffies(500) > > sould do - its only referenced twice and would achieve what you > suggested - initializing it in one location and improved readability > > wait_event_timeout(ctrl->nand_wait, ctrl->nand_stat, IFC_TIMEOUT); > > would there be any disadvantage of this solution? I don't have an issue with the compactness of your code. The issue to me is that msecs_to_jiffies() is a real function call, not a macro. That means that there would be a branch to that function followed by a non-trivial calculation *every* time fsl_ifc_run_command() is called. If the timeout value were calculated during init, then the cost of accessing it would simply a pointer dereference. -Aaron S. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/