All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: <dedekind1@gmail.com>
Cc: Roland Stigge <stigge@antcom.de>,
	srinivas.bakki@nxp.com, Lars-Peter Clausen <lars@metafoo.de>,
	linux-doc@vger.kernel.org, Lei Wen <leiwen@marvell.com>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, kevin.wells@nxp.com,
	linux-mtd@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org, dwmw2@infradead.org,
	Bastian Hecht <hechtb@googlemail.com>
Subject: Re: [PATCH] MTD: LPC32xx SLC NAND driver
Date: Tue, 15 May 2012 16:15:22 +0800	[thread overview]
Message-ID: <4FB2109A.2080505@freescale.com> (raw)
In-Reply-To: <1337068543.2528.143.camel@sauron.fi.intel.com>

于 2012年05月15日 15:55, Artem Bityutskiy 写道:
> I am CCing few other guys who take care of several drivers which use
> similar way of busy-waiting - probably you could change it?
>
> Bastian: drivers/mtd/nand/sh_flctl.c
> Lars-Peter: drivers/mtd/nand/jz4740_nand.c
> Huang: drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> Lei Wen: drivers/mtd/nand/pxa3xx_nand.c
>
> On Sat, 2012-05-12 at 15:29 +0200, Roland Stigge wrote:
>> +       /*
>> +        * The DMA is finished, but the NAND controller may still have
>> +        * buffered data. Wait until all the data is sent.
When all the data is sent, is there an interrupt for this?


Best Regards
Huang Shijie

>> +        */
>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>> +&&  (timeout>  0))
>> +               timeout--;
>> +       if (!timeout) {
>> +               dev_err(mtd->dev.parent, "FIFO held data too long\n");
>> +               status = -EIO;
>> +       }
> I know the MTD tree is full of this, but this is bad, I think. The
> timeout should be time-backed, not CPU-cycles-backed.
>
> I do not know the best way to do this, hopefully someone in the arm list
> could suggest, but the following pattern is at least better:
>
>
> /* Chip reaction time timeout in milliseconds */
> #define LPC32XX_DMA_TIMEOUT 100
>
> timeout = loops_per_jiffy * msecs_to_jiffies(LPC32XX_DMA_TIMEOUT);
>
> while ((readl(...))&&  timeout-->  0)
> 	cpu_relax();
>
> if (!timeout)
> 	error;
>
>
> So basically I turned your hard-coded iterations count into a time-based
> timeout. I also used cpu_relax() which is commonly used in tight-loops
> like this. Here is a piece of documentation about cpu_relax():
>
> "
> The right way to perform a busy wait is:
>
>      while (my_variable != what_i_want)
>          cpu_relax();
>
> The cpu_relax() call can lower CPU power consumption or yield to a
> hyperthreaded twin processor; it also happens to serve as a compiler
> barrier, so, once again, volatile is unnecessary.  Of course, busy-
> waiting is generally an anti-social act to begin with.
> "
>

WARNING: multiple messages have this Message-ID (diff)
From: b32955@freescale.com (Huang Shijie)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MTD: LPC32xx SLC NAND driver
Date: Tue, 15 May 2012 16:15:22 +0800	[thread overview]
Message-ID: <4FB2109A.2080505@freescale.com> (raw)
In-Reply-To: <1337068543.2528.143.camel@sauron.fi.intel.com>

? 2012?05?15? 15:55, Artem Bityutskiy ??:
> I am CCing few other guys who take care of several drivers which use
> similar way of busy-waiting - probably you could change it?
>
> Bastian: drivers/mtd/nand/sh_flctl.c
> Lars-Peter: drivers/mtd/nand/jz4740_nand.c
> Huang: drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> Lei Wen: drivers/mtd/nand/pxa3xx_nand.c
>
> On Sat, 2012-05-12 at 15:29 +0200, Roland Stigge wrote:
>> +       /*
>> +        * The DMA is finished, but the NAND controller may still have
>> +        * buffered data. Wait until all the data is sent.
When all the data is sent, is there an interrupt for this?


Best Regards
Huang Shijie

>> +        */
>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>> +&&  (timeout>  0))
>> +               timeout--;
>> +       if (!timeout) {
>> +               dev_err(mtd->dev.parent, "FIFO held data too long\n");
>> +               status = -EIO;
>> +       }
> I know the MTD tree is full of this, but this is bad, I think. The
> timeout should be time-backed, not CPU-cycles-backed.
>
> I do not know the best way to do this, hopefully someone in the arm list
> could suggest, but the following pattern is at least better:
>
>
> /* Chip reaction time timeout in milliseconds */
> #define LPC32XX_DMA_TIMEOUT 100
>
> timeout = loops_per_jiffy * msecs_to_jiffies(LPC32XX_DMA_TIMEOUT);
>
> while ((readl(...))&&  timeout-->  0)
> 	cpu_relax();
>
> if (!timeout)
> 	error;
>
>
> So basically I turned your hard-coded iterations count into a time-based
> timeout. I also used cpu_relax() which is commonly used in tight-loops
> like this. Here is a piece of documentation about cpu_relax():
>
> "
> The right way to perform a busy wait is:
>
>      while (my_variable != what_i_want)
>          cpu_relax();
>
> The cpu_relax() call can lower CPU power consumption or yield to a
> hyperthreaded twin processor; it also happens to serve as a compiler
> barrier, so, once again, volatile is unnecessary.  Of course, busy-
> waiting is generally an anti-social act to begin with.
> "
>

WARNING: multiple messages have this Message-ID (diff)
From: Huang Shijie <b32955@freescale.com>
To: dedekind1@gmail.com
Cc: Roland Stigge <stigge@antcom.de>,
	Bastian Hecht <hechtb@googlemail.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Lei Wen <leiwen@marvell.com>,
	linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
	dwmw2@infradead.org, kevin.wells@nxp.com, srinivas.bakki@nxp.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] MTD: LPC32xx SLC NAND driver
Date: Tue, 15 May 2012 16:15:22 +0800	[thread overview]
Message-ID: <4FB2109A.2080505@freescale.com> (raw)
In-Reply-To: <1337068543.2528.143.camel@sauron.fi.intel.com>

于 2012年05月15日 15:55, Artem Bityutskiy 写道:
> I am CCing few other guys who take care of several drivers which use
> similar way of busy-waiting - probably you could change it?
>
> Bastian: drivers/mtd/nand/sh_flctl.c
> Lars-Peter: drivers/mtd/nand/jz4740_nand.c
> Huang: drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> Lei Wen: drivers/mtd/nand/pxa3xx_nand.c
>
> On Sat, 2012-05-12 at 15:29 +0200, Roland Stigge wrote:
>> +       /*
>> +        * The DMA is finished, but the NAND controller may still have
>> +        * buffered data. Wait until all the data is sent.
When all the data is sent, is there an interrupt for this?


Best Regards
Huang Shijie

>> +        */
>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>> +&&  (timeout>  0))
>> +               timeout--;
>> +       if (!timeout) {
>> +               dev_err(mtd->dev.parent, "FIFO held data too long\n");
>> +               status = -EIO;
>> +       }
> I know the MTD tree is full of this, but this is bad, I think. The
> timeout should be time-backed, not CPU-cycles-backed.
>
> I do not know the best way to do this, hopefully someone in the arm list
> could suggest, but the following pattern is at least better:
>
>
> /* Chip reaction time timeout in milliseconds */
> #define LPC32XX_DMA_TIMEOUT 100
>
> timeout = loops_per_jiffy * msecs_to_jiffies(LPC32XX_DMA_TIMEOUT);
>
> while ((readl(...))&&  timeout-->  0)
> 	cpu_relax();
>
> if (!timeout)
> 	error;
>
>
> So basically I turned your hard-coded iterations count into a time-based
> timeout. I also used cpu_relax() which is commonly used in tight-loops
> like this. Here is a piece of documentation about cpu_relax():
>
> "
> The right way to perform a busy wait is:
>
>      while (my_variable != what_i_want)
>          cpu_relax();
>
> The cpu_relax() call can lower CPU power consumption or yield to a
> hyperthreaded twin processor; it also happens to serve as a compiler
> barrier, so, once again, volatile is unnecessary.  Of course, busy-
> waiting is generally an anti-social act to begin with.
> "
>



WARNING: multiple messages have this Message-ID (diff)
From: Huang Shijie <b32955@freescale.com>
To: <dedekind1@gmail.com>
Cc: Roland Stigge <stigge@antcom.de>,
	Bastian Hecht <hechtb@googlemail.com>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Lei Wen <leiwen@marvell.com>, <linux-mtd@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
	<devicetree-discuss@lists.ozlabs.org>, <dwmw2@infradead.org>,
	<kevin.wells@nxp.com>, <srinivas.bakki@nxp.com>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] MTD: LPC32xx SLC NAND driver
Date: Tue, 15 May 2012 16:15:22 +0800	[thread overview]
Message-ID: <4FB2109A.2080505@freescale.com> (raw)
In-Reply-To: <1337068543.2528.143.camel@sauron.fi.intel.com>

于 2012年05月15日 15:55, Artem Bityutskiy 写道:
> I am CCing few other guys who take care of several drivers which use
> similar way of busy-waiting - probably you could change it?
>
> Bastian: drivers/mtd/nand/sh_flctl.c
> Lars-Peter: drivers/mtd/nand/jz4740_nand.c
> Huang: drivers/mtd/nand/gpmi-nand/gpmi-lib.c
> Lei Wen: drivers/mtd/nand/pxa3xx_nand.c
>
> On Sat, 2012-05-12 at 15:29 +0200, Roland Stigge wrote:
>> +       /*
>> +        * The DMA is finished, but the NAND controller may still have
>> +        * buffered data. Wait until all the data is sent.
When all the data is sent, is there an interrupt for this?


Best Regards
Huang Shijie

>> +        */
>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>> +&&  (timeout>  0))
>> +               timeout--;
>> +       if (!timeout) {
>> +               dev_err(mtd->dev.parent, "FIFO held data too long\n");
>> +               status = -EIO;
>> +       }
> I know the MTD tree is full of this, but this is bad, I think. The
> timeout should be time-backed, not CPU-cycles-backed.
>
> I do not know the best way to do this, hopefully someone in the arm list
> could suggest, but the following pattern is at least better:
>
>
> /* Chip reaction time timeout in milliseconds */
> #define LPC32XX_DMA_TIMEOUT 100
>
> timeout = loops_per_jiffy * msecs_to_jiffies(LPC32XX_DMA_TIMEOUT);
>
> while ((readl(...))&&  timeout-->  0)
> 	cpu_relax();
>
> if (!timeout)
> 	error;
>
>
> So basically I turned your hard-coded iterations count into a time-based
> timeout. I also used cpu_relax() which is commonly used in tight-loops
> like this. Here is a piece of documentation about cpu_relax():
>
> "
> The right way to perform a busy wait is:
>
>      while (my_variable != what_i_want)
>          cpu_relax();
>
> The cpu_relax() call can lower CPU power consumption or yield to a
> hyperthreaded twin processor; it also happens to serve as a compiler
> barrier, so, once again, volatile is unnecessary.  Of course, busy-
> waiting is generally an anti-social act to begin with.
> "
>



  reply	other threads:[~2012-05-15  8:15 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-12 13:29 [PATCH] MTD: LPC32xx SLC NAND driver Roland Stigge
2012-05-12 13:29 ` Roland Stigge
2012-05-12 13:29 ` Roland Stigge
2012-05-15  7:55 ` Artem Bityutskiy
2012-05-15  7:55   ` Artem Bityutskiy
2012-05-15  7:55   ` Artem Bityutskiy
2012-05-15  8:15   ` Huang Shijie [this message]
2012-05-15  8:15     ` Huang Shijie
2012-05-15  8:15     ` Huang Shijie
2012-05-15  8:15     ` Huang Shijie
2012-05-15 13:20     ` Roland Stigge
2012-05-15 13:20       ` Roland Stigge
2012-05-15 13:20       ` Roland Stigge
2012-05-15 13:31       ` Artem Bityutskiy
2012-05-15 13:31         ` Artem Bityutskiy
2012-05-15 13:31         ` Artem Bityutskiy
2012-05-15 13:48         ` Roland Stigge
2012-05-15 13:48           ` Roland Stigge
2012-05-15 13:48           ` Roland Stigge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB2109A.2080505@freescale.com \
    --to=b32955@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dwmw2@infradead.org \
    --cc=hechtb@googlemail.com \
    --cc=kevin.wells@nxp.com \
    --cc=lars@metafoo.de \
    --cc=leiwen@marvell.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=srinivas.bakki@nxp.com \
    --cc=stigge@antcom.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.