All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: H Hartley Sweeten <hartleys@visionengravers.com>
Cc: "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>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] sst25l.c: simplify reading the device ManID/DevID
Date: Thu, 29 Apr 2010 21:07:46 +0300	[thread overview]
Message-ID: <1272564466.2593.3.camel@localhost.localdomain> (raw)
In-Reply-To: <0D753D10438DA54287A00B0270842697636E305B2F@AUSP01VMBX24.collaborationhost.net>

On Thu, 2010-04-29 at 12:11 -0500, H Hartley Sweeten wrote:
> On Wednesday, April 28, 2010 10:37 PM, Artem Bityutskiy wrote:
> > On Tue, 2010-04-20 at 18:17 -0500, H Hartley Sweeten wrote:
> >> The Read-ID command will continuously output the Manufacture ID and Device ID
> >> until the command is terminated by a low to high transition on the CE# pin.
> >> We can take advantage of this in the sst25l_match_device routine by reading
> >> both bytes in one spi_write_then_read transaction.
> >> 
> >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> >> Cc: David Woodhouse <dwmw2@infradead.org>
> >> Cc: Andre Renaud <andre@bluewatersys.com>
> >> Cc: Ryan Mallon <ryan@bluewatersys.com>
> >
> > Pushed to l2-mtd-2.6.git / dunno.
> 
> Artem,
> 
> I have discovered that the Read-Status-Register command has the same problem.
> With the SST25L SPI flash chips, if the chip enable is deasserted after sending
> a command that command will get aborted.
> 
> I ran across this while testing a new spi master driver for the ep93xx on an
> EDB9307A dev board.  That board uses the processors SFRMOUT signal as part of
> the chip select logic.  Unfortunately the ep93xx only asserts the SFRMOUT
> signal as long as the spi transmit fifo contains data.  As soon as the last
> bit is clocked into the receive fifo it gets deasserted.  Many of the other
> ep93xx based boards have that same issue.
> 
> I have an updated patch that changes both of these into one synchronous message
> which fixes the sst25l_status and sst25l_match_device functions.  These changes
> should be transparent to any users of this driver.
> 
> Could you drop the current patch and I will submit the updated one for review?

Of course, just send it.

-- 
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: 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: simplify reading the device ManID/DevID
Date: Thu, 29 Apr 2010 21:07:46 +0300	[thread overview]
Message-ID: <1272564466.2593.3.camel@localhost.localdomain> (raw)
In-Reply-To: <0D753D10438DA54287A00B0270842697636E305B2F@AUSP01VMBX24.collaborationhost.net>

On Thu, 2010-04-29 at 12:11 -0500, H Hartley Sweeten wrote:
> On Wednesday, April 28, 2010 10:37 PM, Artem Bityutskiy wrote:
> > On Tue, 2010-04-20 at 18:17 -0500, H Hartley Sweeten wrote:
> >> The Read-ID command will continuously output the Manufacture ID and Device ID
> >> until the command is terminated by a low to high transition on the CE# pin.
> >> We can take advantage of this in the sst25l_match_device routine by reading
> >> both bytes in one spi_write_then_read transaction.
> >> 
> >> Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
> >> Cc: David Woodhouse <dwmw2@infradead.org>
> >> Cc: Andre Renaud <andre@bluewatersys.com>
> >> Cc: Ryan Mallon <ryan@bluewatersys.com>
> >
> > Pushed to l2-mtd-2.6.git / dunno.
> 
> Artem,
> 
> I have discovered that the Read-Status-Register command has the same problem.
> With the SST25L SPI flash chips, if the chip enable is deasserted after sending
> a command that command will get aborted.
> 
> I ran across this while testing a new spi master driver for the ep93xx on an
> EDB9307A dev board.  That board uses the processors SFRMOUT signal as part of
> the chip select logic.  Unfortunately the ep93xx only asserts the SFRMOUT
> signal as long as the spi transmit fifo contains data.  As soon as the last
> bit is clocked into the receive fifo it gets deasserted.  Many of the other
> ep93xx based boards have that same issue.
> 
> I have an updated patch that changes both of these into one synchronous message
> which fixes the sst25l_status and sst25l_match_device functions.  These changes
> should be transparent to any users of this driver.
> 
> Could you drop the current patch and I will submit the updated one for review?

Of course, just send it.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)


  reply	other threads:[~2010-04-29 18:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-20 23:17 [PATCH] sst25l.c: simplify reading the device ManID/DevID H Hartley Sweeten
2010-04-20 23:17 ` H Hartley Sweeten
2010-04-29  5:36 ` Artem Bityutskiy
2010-04-29 17:11   ` H Hartley Sweeten
2010-04-29 17:11     ` H Hartley Sweeten
2010-04-29 18:07     ` Artem Bityutskiy [this message]
2010-04-29 18:07       ` 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=1272564466.2593.3.camel@localhost.localdomain \
    --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.