mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Jagan Teki <jagan@openedev.com>
Cc: Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	Brian Norris <computersforpeace@gmail.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	nicolas.ferre@atmel.com, boris.brezillon@free-electrons.com,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories
Date: Mon, 24 Oct 2016 13:41:49 +0200	[thread overview]
Message-ID: <e9eb9848-522d-2889-457b-d8060f89b352@denx.de> (raw)
In-Reply-To: <CAD6G_RQ2BjtF2cmPUJvYNk7KZZ6eTVAQsEqWs26xn710A4Dz-w@mail.gmail.com>

On 10/24/2016 09:41 AM, Jagan Teki wrote:
> On Sun, Oct 23, 2016 at 2:03 AM, Marek Vasut <marex@denx.de> wrote:
>> On 10/22/2016 01:00 PM, Jagan Teki wrote:
>>> On Wed, Oct 5, 2016 at 5:30 PM, Cyrille Pitchen
>>> <cyrille.pitchen@atmel.com> wrote:
>>>> Hi all,
>>>>
>>>> This series extends support of SPI protocols to new protocols such as
>>>> SPI x-2-2 and SPI x-4-4. Also spi_nor_scan() tries now to select the right
>>>> op codes, timing parameters (number of mode and dummy cycles) and erase
>>>> sector size by parsing the Serial Flash Discoverable Parameter (SFDP)
>>>> tables, when available, as defined in the JEDEC JESD216 specifications.
>>>>
>>>> When SFDP tables are not available, legacy settings are still used for
>>>> backward compatibility (SPI and earlier QSPI memories).
>>>>
>>>> Support of SPI memories >128Mbits is also improved by using the 4byte
>>>> address instruction set, when available. Using those dedicated op codes
>>>> is stateless as opposed to enter the 4byte address mode, hence a better
>>>> compatibility with some boot loaders which expect to use 3byte address
>>>> op codes.
>>>
>>> The memories which are > 128Mbits should have 4-bytes addressing
>>> support based on my experience, do you think BAR is also required
>>> atleast from spi-nor side?
>>
>> Yes, I believe BAR is still required for broken/dumb flash chips.
>> Not all chips > 16 MiB support dedicated 4-byte addressing opcodes :-(
> 
> Do you have list for those broken chips?

No.

> because I never find any
> chips which has > 16 MiB with not support of 4-byte address opcodes
> and I've seen the controller has dependable with BAR though it can
> access > 16MiB ex: zynq qspi/

IIRC some of the 32 MiB micron chips were pretty flaky in that aspect,
they used the same opcodes for 4byte access as for 3byte access and
their behavior was switched by writing some non-volatile bit.

-- 
Best regards,
Marek Vasut

  reply	other threads:[~2016-10-24 11:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-05 12:00 Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 1/9] mtd: spi-nor: improve macronix_quad_enable() Cyrille Pitchen
2016-10-24  7:35   ` Jagan Teki
2016-10-05 12:00 ` [PATCH v2 2/9] mtd: spi-nor: add an alternative method to support memory >16MiB Cyrille Pitchen
2016-10-13 12:11   ` Vignesh R
2016-10-05 12:00 ` [PATCH v2 3/9] mtd: spi-nor: add support of SPI protocols like SPI 1-2-2 and SPI 1-4-4 Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 4/9] mtd: spi-nor: remove unused set_quad_mode() function Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 5/9] mtd: m25p80: add support of dual and quad spi protocols to all commands Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 6/9] mtd: spi-nor: parse Serial Flash Discoverable Parameters (SFDP) tables Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 7/9] mtd: spi-nor: parse SFDP 4-byte Address Instruction Table Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 8/9] mtd: spi-nor: add support to Macronix mx66l1g45g Cyrille Pitchen
2016-10-05 12:00 ` [PATCH v2 9/9] mtd: spi-nor: add support to SST sst26* QSPI memories Cyrille Pitchen
2016-10-22 11:00 ` [PATCH v2 0/9] mtd: spi-nor: parse SFDP tables to setup (Q)SPI memories Jagan Teki
2016-10-22 20:33   ` Marek Vasut
2016-10-24  7:41     ` Jagan Teki
2016-10-24 11:41       ` Marek Vasut [this message]
2016-10-24 12:09       ` Cyrille Pitchen
2016-10-24 14:07         ` Cyrille Pitchen
2016-10-25  9:08           ` Jagan Teki
2016-10-25 19:59             ` Jagan Teki

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=e9eb9848-522d-2889-457b-d8060f89b352@denx.de \
    --to=marex@denx.de \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=jagan@openedev.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=nicolas.ferre@atmel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®