From: Artem Bityutskiy <dedekind1@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
"ryan@bluewatersys.com" <ryan@bluewatersys.com>,
"andre@bluewatersys.com" <andre@bluewatersys.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sst25l.c: fix multi-part messages with broken spi masters
Date: Wed, 05 May 2010 08:45:49 +0300 [thread overview]
Message-ID: <1273038349.3702.54.camel@localhost> (raw)
In-Reply-To: <0D753D10438DA54287A00B0270842697636E305D4A@AUSP01VMBX24.collaborationhost.net>
On Thu, 2010-04-29 at 13:34 -0500, H Hartley Sweeten wrote:
> Some SPI masters (ep93xx) have limitations when using the SFRMOUT
> signal for the spi device chip select. The SFRMOUT signal is
> only asserted as long as the spi transmit fifo contains data. As
> soon as the last bit is clocked into the receive fifo it gets
> deasserted.
>
> The functions sst25l_status and sst25l_match_device use the API
> function spi_write_then_read to write a command to the flash then
> read the response back. This API function creates a two part spi
> message for the write then read. When this message is transferred
> the SFRMOUT signal ends up getting deasserted after the command
> phase. This causes the command to get aborted by the device so
> the read phase returns invalid data.
>
> By changing sst25l_status and sst25l_match_device to use a single
> transfer synchronous message, the SFRMOUT signal stays asserted
> during the entire message so the correct data always gets returned.
>
> This change will have no effect on SPI masters which use a chip
> select mechanism (GPIO's, etc.) which does stay asserted correctly.
> As a bonus, the single transfer synchronous messages complete faster
> than multi-part messages.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Andre Renaud <andre@bluewatersys.com>
> Cc: Ryan Mallon <ryan@bluewatersys.com>
Pushed to l2-mtd-2.6 / dunno.
But please, notice for future:
1. It is much nicer to put something like [PATCH v2] when you re-send.
2. In MTD we prefix everything with mtd:
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
WARNING: multiple messages have this Message-ID (diff)
From: Artem Bityutskiy <dedekind1@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"ryan@bluewatersys.com" <ryan@bluewatersys.com>,
"andre@bluewatersys.com" <andre@bluewatersys.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] sst25l.c: fix multi-part messages with broken spi masters
Date: Wed, 05 May 2010 08:45:49 +0300 [thread overview]
Message-ID: <1273038349.3702.54.camel@localhost> (raw)
In-Reply-To: <0D753D10438DA54287A00B0270842697636E305D4A@AUSP01VMBX24.collaborationhost.net>
On Thu, 2010-04-29 at 13:34 -0500, H Hartley Sweeten wrote:
> Some SPI masters (ep93xx) have limitations when using the SFRMOUT
> signal for the spi device chip select. The SFRMOUT signal is
> only asserted as long as the spi transmit fifo contains data. As
> soon as the last bit is clocked into the receive fifo it gets
> deasserted.
>
> The functions sst25l_status and sst25l_match_device use the API
> function spi_write_then_read to write a command to the flash then
> read the response back. This API function creates a two part spi
> message for the write then read. When this message is transferred
> the SFRMOUT signal ends up getting deasserted after the command
> phase. This causes the command to get aborted by the device so
> the read phase returns invalid data.
>
> By changing sst25l_status and sst25l_match_device to use a single
> transfer synchronous message, the SFRMOUT signal stays asserted
> during the entire message so the correct data always gets returned.
>
> This change will have no effect on SPI masters which use a chip
> select mechanism (GPIO's, etc.) which does stay asserted correctly.
> As a bonus, the single transfer synchronous messages complete faster
> than multi-part messages.
>
> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> Cc: David Woodhouse <dwmw2@infradead.org>
> Cc: Artem Bityutskiy <dedekind1@gmail.com>
> Cc: Andre Renaud <andre@bluewatersys.com>
> Cc: Ryan Mallon <ryan@bluewatersys.com>
Pushed to l2-mtd-2.6 / dunno.
But please, notice for future:
1. It is much nicer to put something like [PATCH v2] when you re-send.
2. In MTD we prefix everything with mtd:
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-05-05 5:45 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-29 18:34 [PATCH] sst25l.c: fix multi-part messages with broken spi masters H Hartley Sweeten
2010-04-29 18:34 ` H Hartley Sweeten
2010-05-05 5:45 ` Artem Bityutskiy [this message]
2010-05-05 5:45 ` Artem Bityutskiy
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=1273038349.3702.54.camel@localhost \
--to=dedekind1@gmail.com \
--cc=andre@bluewatersys.com \
--cc=dwmw2@infradead.org \
--cc=hartleys@visionengravers.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=ryan@bluewatersys.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.