From: Angus Clark <angus.clark@st.com>
To: "Gupta, Pekon" <pekon@ti.com>
Cc: "marex@denx.de" <marex@denx.de>, Angus CLARK <angus.clark@st.com>,
"broonie@linaro.org" <broonie@linaro.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
Linus Walleij <linus.walleij@linaro.org>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
Huang Shijie <b32955@freescale.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"Poddar, Sourav" <sourav.poddar@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Date: Wed, 4 Dec 2013 08:21:05 +0000 [thread overview]
Message-ID: <529EE5F1.9080806@st.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA51905@DBDE04.ent.ti.com>
Hi Pekon,
On 12/04/2013 07:19 AM, Gupta, Pekon wrote:
> Unless a register is controlling a status of internal state-machine, or something
> It should be instantaneously writable.
Yes, that is my point. Some register writes are instant, other are not,
particularly those that involve non-volatile status or configuration bits.
> Also polling should not be part of this particular *(write_reg), if a register
> needs to be polled then it should be part of *(write) or *(read) .. Like
> WIP: Write-in-progress bit of flash
> generic_flash_write(...) {
> while ((read_reg(STATUS_REG) & WIP) || ~timeout) {
> timeout--;
> };
I am in two minds about where the WTR loop should live. On the one hand, moving
it to the "generic_flash_write()" call offers H/W controllers the opportunity to
optimise the polling, if they support such a feature (I know of some that will
in the future).
However, requiring the H/W driver to perform the polling, including knowledge of
the STATUS CMD, and the WIP bit-field, just seems like moving too much
"intelligence" away from the spi-nor layer. What concerns me is when we get on
to reading/clearing error flags (as now mandated on some Serial Flash devices,
e.g. n25p512 and n25q00a), this will also need to be part of the generic write.
> With this it just came to my mind, that you also need a 'timeout' field
> in 'struct spinor-cfg'.
Yes, that is a good point.
I would propose that the spi-nor layer retains responsibility for determining
whether or not 'WTR' is required for a particular operation, and a suitable
timeout. At some point, during initialisation, the H/W driver will need to
inform the spi-nor layer about its capabilities (e.g. support for DUAL or QUAD
mode, any warm-reset requirements, etc), and native support of WIP polling could
be part of this set. The spi-nor layer could then decide whether to add the WTR
flag and timeout to the spinor-cfg transfer, or to take responsibility itself,
and execute its own polling loop. This gives greatest flexibility, which seems
to be an important factor, while retaining the knowledge in the spi-nor layer.
Cheers,
Angus
WARNING: multiple messages have this Message-ID (diff)
From: Angus Clark <angus.clark-qxv4g6HH51o@public.gmane.org>
To: "Gupta, Pekon" <pekon-l0cyMroinI0@public.gmane.org>
Cc: Huang Shijie <b32955-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
Brian Norris
<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"marex-ynQEQJNshbs@public.gmane.org"
<marex-ynQEQJNshbs@public.gmane.org>,
"broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Linus Walleij
<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"Poddar, Sourav" <sourav.poddar-l0cyMroinI0@public.gmane.org>,
"dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org"
<dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Angus CLARK <angus.clark-qxv4g6HH51o@public.gmane.org>
Subject: Re: [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Date: Wed, 4 Dec 2013 08:21:05 +0000 [thread overview]
Message-ID: <529EE5F1.9080806@st.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA51905-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
Hi Pekon,
On 12/04/2013 07:19 AM, Gupta, Pekon wrote:
> Unless a register is controlling a status of internal state-machine, or something
> It should be instantaneously writable.
Yes, that is my point. Some register writes are instant, other are not,
particularly those that involve non-volatile status or configuration bits.
> Also polling should not be part of this particular *(write_reg), if a register
> needs to be polled then it should be part of *(write) or *(read) .. Like
> WIP: Write-in-progress bit of flash
> generic_flash_write(...) {
> while ((read_reg(STATUS_REG) & WIP) || ~timeout) {
> timeout--;
> };
I am in two minds about where the WTR loop should live. On the one hand, moving
it to the "generic_flash_write()" call offers H/W controllers the opportunity to
optimise the polling, if they support such a feature (I know of some that will
in the future).
However, requiring the H/W driver to perform the polling, including knowledge of
the STATUS CMD, and the WIP bit-field, just seems like moving too much
"intelligence" away from the spi-nor layer. What concerns me is when we get on
to reading/clearing error flags (as now mandated on some Serial Flash devices,
e.g. n25p512 and n25q00a), this will also need to be part of the generic write.
> With this it just came to my mind, that you also need a 'timeout' field
> in 'struct spinor-cfg'.
Yes, that is a good point.
I would propose that the spi-nor layer retains responsibility for determining
whether or not 'WTR' is required for a particular operation, and a suitable
timeout. At some point, during initialisation, the H/W driver will need to
inform the spi-nor layer about its capabilities (e.g. support for DUAL or QUAD
mode, any warm-reset requirements, etc), and native support of WIP polling could
be part of this set. The spi-nor layer could then decide whether to add the WTR
flag and timeout to the spinor-cfg transfer, or to take responsibility itself,
and execute its own polling loop. This gives greatest flexibility, which seems
to be an important factor, while retaining the knowledge in the spi-nor layer.
Cheers,
Angus
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: angus.clark@st.com (Angus Clark)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR
Date: Wed, 4 Dec 2013 08:21:05 +0000 [thread overview]
Message-ID: <529EE5F1.9080806@st.com> (raw)
In-Reply-To: <20980858CB6D3A4BAE95CA194937D5E73EA51905@DBDE04.ent.ti.com>
Hi Pekon,
On 12/04/2013 07:19 AM, Gupta, Pekon wrote:
> Unless a register is controlling a status of internal state-machine, or something
> It should be instantaneously writable.
Yes, that is my point. Some register writes are instant, other are not,
particularly those that involve non-volatile status or configuration bits.
> Also polling should not be part of this particular *(write_reg), if a register
> needs to be polled then it should be part of *(write) or *(read) .. Like
> WIP: Write-in-progress bit of flash
> generic_flash_write(...) {
> while ((read_reg(STATUS_REG) & WIP) || ~timeout) {
> timeout--;
> };
I am in two minds about where the WTR loop should live. On the one hand, moving
it to the "generic_flash_write()" call offers H/W controllers the opportunity to
optimise the polling, if they support such a feature (I know of some that will
in the future).
However, requiring the H/W driver to perform the polling, including knowledge of
the STATUS CMD, and the WIP bit-field, just seems like moving too much
"intelligence" away from the spi-nor layer. What concerns me is when we get on
to reading/clearing error flags (as now mandated on some Serial Flash devices,
e.g. n25p512 and n25q00a), this will also need to be part of the generic write.
> With this it just came to my mind, that you also need a 'timeout' field
> in 'struct spinor-cfg'.
Yes, that is a good point.
I would propose that the spi-nor layer retains responsibility for determining
whether or not 'WTR' is required for a particular operation, and a suitable
timeout. At some point, during initialisation, the H/W driver will need to
inform the spi-nor layer about its capabilities (e.g. support for DUAL or QUAD
mode, any warm-reset requirements, etc), and native support of WIP polling could
be part of this set. The spi-nor layer could then decide whether to add the WTR
flag and timeout to the spinor-cfg transfer, or to take responsibility itself,
and execute its own polling loop. This gives greatest flexibility, which seems
to be an important factor, while retaining the knowledge in the spi-nor layer.
Cheers,
Angus
next prev parent reply other threads:[~2013-12-04 8:21 UTC|newest]
Thread overview: 157+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-26 6:32 [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 6:32 ` [PATCH 1/4] mtd: spi-nor: move the SPI NOR commands to a new header file Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 7:42 ` Gupta, Pekon
2013-11-26 7:42 ` Gupta, Pekon
2013-11-26 8:53 ` Huang Shijie
2013-11-26 8:53 ` Huang Shijie
2013-11-26 14:48 ` Angus Clark
2013-11-26 14:48 ` Angus Clark
2013-11-26 6:32 ` [PATCH 2/4] mtd: spi-nor: add a new data structrue spi_nor{} Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 11:42 ` Gupta, Pekon
2013-11-26 11:42 ` Gupta, Pekon
2013-11-27 4:35 ` Huang Shijie
2013-11-27 4:35 ` Huang Shijie
2013-11-27 9:32 ` Marek Vasut
2013-11-27 9:32 ` Marek Vasut
2013-11-27 10:24 ` Huang Shijie
2013-11-27 10:24 ` Huang Shijie
2013-11-27 10:27 ` Marek Vasut
2013-11-27 10:27 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 3/4] mtd: spi-nor: add the framework for SPI NOR Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 10:03 ` Gupta, Pekon
2013-11-26 10:03 ` Gupta, Pekon
2013-11-27 9:39 ` Marek Vasut
2013-11-27 9:39 ` Marek Vasut
2013-11-26 6:32 ` [PATCH 4/4] mtd: m25p80: use the new spi-nor APIs Huang Shijie
2013-11-26 6:32 ` Huang Shijie
2013-11-26 12:57 ` [PATCH 0/4] mtd: spi-nor: add a new framework for SPI NOR Angus Clark
2013-11-26 12:57 ` Angus Clark
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:32 ` Brian Norris
2013-11-27 4:39 ` Huang Shijie
2013-11-27 4:39 ` Huang Shijie
2013-11-27 4:39 ` Huang Shijie
2013-11-29 14:52 ` Angus Clark
2013-11-29 14:52 ` Angus Clark
2013-11-29 14:52 ` Angus Clark
2013-12-02 10:06 ` Huang Shijie
2013-12-02 10:06 ` Huang Shijie
2013-12-02 10:06 ` Huang Shijie
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:01 ` Gupta, Pekon
2013-12-02 11:19 ` Angus Clark
2013-12-02 11:19 ` Angus Clark
2013-12-03 6:20 ` Huang Shijie
2013-12-03 6:20 ` Huang Shijie
2013-12-03 6:20 ` Huang Shijie
2013-12-03 8:23 ` Lee Jones
2013-12-03 8:23 ` Lee Jones
2013-12-03 8:23 ` Lee Jones
2013-12-10 8:25 ` Brian Norris
2013-12-10 8:25 ` Brian Norris
2013-12-10 8:25 ` Brian Norris
2013-12-10 10:00 ` Lee Jones
2013-12-10 10:00 ` Lee Jones
2013-12-10 10:00 ` Lee Jones
2013-12-03 0:32 ` Marek Vasut
2013-12-03 0:32 ` Marek Vasut
2013-12-03 0:32 ` Marek Vasut
2013-12-03 10:36 ` Huang Shijie
2013-12-03 10:36 ` Huang Shijie
2013-12-03 10:36 ` Huang Shijie
2013-12-03 14:51 ` David Woodhouse
2013-12-03 14:51 ` David Woodhouse
2013-12-03 14:51 ` David Woodhouse
2013-12-04 18:44 ` Brian Norris
2013-12-04 18:44 ` Brian Norris
2013-12-04 18:44 ` Brian Norris
2013-12-05 7:12 ` Huang Shijie
2013-12-05 7:12 ` Huang Shijie
2013-12-05 7:12 ` Huang Shijie
2013-12-05 8:11 ` Brian Norris
2013-12-05 8:11 ` Brian Norris
2013-12-05 8:11 ` Brian Norris
2013-12-05 7:59 ` Huang Shijie
2013-12-05 7:59 ` Huang Shijie
2013-12-05 7:59 ` Huang Shijie
2013-12-05 9:20 ` Brian Norris
2013-12-05 9:20 ` Brian Norris
2013-12-05 9:20 ` Brian Norris
2013-12-06 3:07 ` Huang Shijie
2013-12-06 3:07 ` Huang Shijie
2013-12-06 3:07 ` Huang Shijie
2013-12-05 14:35 ` Angus Clark
2013-12-05 14:35 ` Angus Clark
2013-12-05 14:35 ` Angus Clark
2013-12-06 8:18 ` Huang Shijie
2013-12-06 8:18 ` Huang Shijie
2013-12-06 8:18 ` Huang Shijie
2013-12-10 9:08 ` Brian Norris
2013-12-10 9:08 ` Brian Norris
2013-12-10 9:08 ` Brian Norris
2013-12-04 2:46 ` Huang Shijie
2013-12-04 2:46 ` Huang Shijie
2013-12-04 2:46 ` Huang Shijie
2013-12-04 6:58 ` Angus Clark
2013-12-04 6:58 ` Angus Clark
2013-12-04 6:58 ` Angus Clark
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 7:19 ` Gupta, Pekon
2013-12-04 8:21 ` Angus Clark [this message]
2013-12-04 8:21 ` Angus Clark
2013-12-04 8:21 ` Angus Clark
2013-12-04 15:36 ` Marek Vasut
2013-12-04 15:36 ` Marek Vasut
2013-12-04 15:36 ` Marek Vasut
2013-12-05 2:42 ` Huang Shijie
2013-12-05 2:42 ` Huang Shijie
2013-12-05 2:42 ` Huang Shijie
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 5:43 ` Gupta, Pekon
2013-12-05 7:33 ` Huang Shijie
2013-12-05 7:33 ` Huang Shijie
2013-12-05 7:33 ` Huang Shijie
2013-11-27 9:27 ` Marek Vasut
2013-11-27 9:27 ` Marek Vasut
2013-11-27 9:47 ` Sourav Poddar
2013-11-27 9:47 ` Sourav Poddar
2013-11-27 10:06 ` Marek Vasut
2013-11-27 10:06 ` Marek Vasut
2013-11-27 10:56 ` Sourav Poddar
2013-11-27 10:56 ` Sourav Poddar
2013-12-02 23:59 ` Marek Vasut
2013-12-02 23:59 ` Marek Vasut
2013-12-03 10:01 ` Sourav Poddar
2013-12-03 10:01 ` Sourav Poddar
2013-12-03 13:42 ` Marek Vasut
2013-12-03 13:42 ` Marek Vasut
2013-12-03 13:50 ` Sourav Poddar
2013-12-03 13:50 ` Sourav Poddar
2013-12-03 14:19 ` Marek Vasut
2013-12-03 14:19 ` Marek Vasut
2013-12-03 14:31 ` Sourav Poddar
2013-12-03 14:31 ` Sourav Poddar
2013-12-03 15:09 ` Marek Vasut
2013-12-03 15:09 ` Marek Vasut
2013-12-03 15:16 ` Sourav Poddar
2013-12-03 15:16 ` Sourav Poddar
2013-12-03 15:35 ` Marek Vasut
2013-12-03 15:35 ` Marek Vasut
2013-12-03 15:23 ` David Woodhouse
2013-12-03 15:23 ` David Woodhouse
2013-12-03 18:28 ` Brian Norris
2013-12-03 18:28 ` Brian Norris
2013-12-03 23:41 ` Marek Vasut
2013-12-03 23:41 ` Marek Vasut
2013-11-27 10:19 ` Huang Shijie
2013-11-27 10:19 ` Huang Shijie
2013-12-03 0:00 ` Marek Vasut
2013-12-03 0:00 ` Marek Vasut
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=529EE5F1.9080806@st.com \
--to=angus.clark@st.com \
--cc=b32955@freescale.com \
--cc=broonie@linaro.org \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=lee.jones@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=marex@denx.de \
--cc=pekon@ti.com \
--cc=sourav.poddar@ti.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.