All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Adam Somerville <adamsomerville@gmail.com>
Cc: "Bean Huo 霍斌斌 (beanhuo)" <beanhuo@micron.com>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Brian Norris" <computersforpeace@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"zajec5@gmail.com" <zajec5@gmail.com>,
	"jteki@openedev.com" <jteki@openedev.com>,
	"mika.westerberg@linux.intel.com"
	<mika.westerberg@linux.intel.com>,
	"furquan@google.com" <furquan@google.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] spi-nor: fix cross die reads on Micron multi-die devices
Date: Wed, 20 Jan 2016 13:24:33 +0100	[thread overview]
Message-ID: <20160120132433.3d201299@bbrezillon> (raw)
In-Reply-To: <CAJorgdvD9WCsHCoRt05tn-vh_1oqsCZiMehbVKQtynocxX_-wQ@mail.gmail.com>

Adam, Bean,

On Wed, 20 Jan 2016 12:01:06 +0000
Adam Somerville <adamsomerville@gmail.com> wrote:

> Hi,
> 
> Thanks for looking at the this.
> 
> I can rewrite so it only affects N25Q devices, I hoped a simpler
> implementation would outweigh the small overhead incurred on non
> affected devices.

I tend to think the same way: not sure the performance penalty is worth
the pain.

Best Regards,

Boris

> 
> Do you know if there are any plans for MT25* based multi-die devices
> and if they would have the same issue?
> 
> Thanks,
> 
> Adam
> 
> On Wed, Jan 20, 2016 at 2:45 AM, Bean Huo 霍斌斌 (beanhuo)
> <beanhuo@micron.com> wrote:
> > Hi, Adam
> > This is true, but this only exist in Micron 65nm spi nor N25Q.
> > For our 45nm spi nor MT25Q , MT25TL and MT25Q, does exist this question.
> > So I think, can you differentiate between these in your patch?
> >
> >> From: Adam Somerville <adamsomerville@gmail.com>
> >>
> >> So as far as I can see there is a bug in the spi-nor driver when issuing die
> >> boundary crossing reads on Micron multi-die devices.
> >> Micron N25Q512A, N25Q00AA and probably any other Micron multi-die
> >> devices do not support a single read request that crosses a die boundary.
> >>
> >> The current behaviour is that the address on the device wraps back to the
> >> start of the first die, with any data returned beyond the boundary being from
> >> the start of the first die.
> >>



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

  reply	other threads:[~2016-01-20 12:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-20  2:45 [RFC] spi-nor: fix cross die reads on Micron multi-die devices Bean Huo 霍斌斌 (beanhuo)
2016-01-20 12:01 ` Adam Somerville
2016-01-20 12:24   ` Boris Brezillon [this message]
2016-01-21  1:06   ` Bean Huo 霍斌斌 (beanhuo)
2016-01-21  8:56     ` Boris Brezillon
2016-01-22  7:00       ` Bean Huo 霍斌斌 (beanhuo)
  -- strict thread matches above, loose matches on Subject: below --
2016-01-19 15:01 adamsomerville

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=20160120132433.3d201299@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=adamsomerville@gmail.com \
    --cc=beanhuo@micron.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=furquan@google.com \
    --cc=jteki@openedev.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=zajec5@gmail.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.