All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Stigge <stigge@antcom.de>
To: Huang Shijie <b32955@freescale.com>
Cc: srinivas.bakki@nxp.com, Lars-Peter Clausen <lars@metafoo.de>,
	dedekind1@gmail.com, Lei Wen <leiwen@marvell.com>,
	devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.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 15:20:55 +0200	[thread overview]
Message-ID: <4FB25837.2050603@antcom.de> (raw)
In-Reply-To: <4FB2109A.2080505@freescale.com>

Hi Artem and Huang,

thank you for your feedback!

On 05/15/2012 10:15 AM, Huang Shijie wrote:
>> 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?

Bad news is: No

Good news is: The previous DMA operation finished with an interrupt
which according to the manual should already corresponds to this
condition. Tests show that at this point of sampling:

>>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>>> +&&  (timeout>  0))
>>> +               timeout--;

... the condition is always true and always just jumps over this loop,
at least with my hardware.

>> /* 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();

As I understand loops_per_jiffy, this loop will take much longer than
the 100 ms you defined above?

Anyway, I will keep the loop for safety reasons, add an msleep() and add
a warning, should the loop be entered _at all_.

Maybe someone from NXP can give us more insight here? Maybe the
condition check isn't necessary anymore after I ported the driver to
dmaengine (this controller is always wired together with an amba-pl080
in the LPC32xx)?

Thanks in advance,

Roland

WARNING: multiple messages have this Message-ID (diff)
From: stigge@antcom.de (Roland Stigge)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] MTD: LPC32xx SLC NAND driver
Date: Tue, 15 May 2012 15:20:55 +0200	[thread overview]
Message-ID: <4FB25837.2050603@antcom.de> (raw)
In-Reply-To: <4FB2109A.2080505@freescale.com>

Hi Artem and Huang,

thank you for your feedback!

On 05/15/2012 10:15 AM, Huang Shijie wrote:
>> 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?

Bad news is: No

Good news is: The previous DMA operation finished with an interrupt
which according to the manual should already corresponds to this
condition. Tests show that at this point of sampling:

>>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>>> +&&  (timeout>  0))
>>> +               timeout--;

... the condition is always true and always just jumps over this loop,
at least with my hardware.

>> /* 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();

As I understand loops_per_jiffy, this loop will take much longer than
the 100 ms you defined above?

Anyway, I will keep the loop for safety reasons, add an msleep() and add
a warning, should the loop be entered _at all_.

Maybe someone from NXP can give us more insight here? Maybe the
condition check isn't necessary anymore after I ported the driver to
dmaengine (this controller is always wired together with an amba-pl080
in the LPC32xx)?

Thanks in advance,

Roland

WARNING: multiple messages have this Message-ID (diff)
From: Roland Stigge <stigge@antcom.de>
To: Huang Shijie <b32955@freescale.com>
Cc: dedekind1@gmail.com, 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 15:20:55 +0200	[thread overview]
Message-ID: <4FB25837.2050603@antcom.de> (raw)
In-Reply-To: <4FB2109A.2080505@freescale.com>

Hi Artem and Huang,

thank you for your feedback!

On 05/15/2012 10:15 AM, Huang Shijie wrote:
>> 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?

Bad news is: No

Good news is: The previous DMA operation finished with an interrupt
which according to the manual should already corresponds to this
condition. Tests show that at this point of sampling:

>>> +       timeout = LPC32XX_DMA_SIMPLE_TIMEOUT;
>>> +       while ((readl(SLC_STAT(host->io_base))&  SLCSTAT_DMA_FIFO)
>>> +&&  (timeout>  0))
>>> +               timeout--;

... the condition is always true and always just jumps over this loop,
at least with my hardware.

>> /* 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();

As I understand loops_per_jiffy, this loop will take much longer than
the 100 ms you defined above?

Anyway, I will keep the loop for safety reasons, add an msleep() and add
a warning, should the loop be entered _at all_.

Maybe someone from NXP can give us more insight here? Maybe the
condition check isn't necessary anymore after I ported the driver to
dmaengine (this controller is always wired together with an amba-pl080
in the LPC32xx)?

Thanks in advance,

Roland

  reply	other threads:[~2012-05-15 13:20 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
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 [this message]
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=4FB25837.2050603@antcom.de \
    --to=stigge@antcom.de \
    --cc=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 \
    /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.